Mục lục

Lời giới thiệu cho Loạt sách Tinh gọn

Lời tựa

PHẦN I: ĐỊNH HƯỚNG

Chương 1: Giới thiệu

Chương 2: Quản lý tính năng động của Hồ sơ Doanh nghiệp

PHẦN II: KHÁM PHÁ

Chương 3: Định hình và đánh giá rủi ro đầu tư

Chương 4: Khám phá tính bất trắc để phát hiện các cơ hội

Chương 5: Đánh giá sự hòa hợp giữa sản phẩm/thị trường

PHẦN III: KHAI THÁC

Chương 6: Cải tiến liên tục

Chương 7: Nhận biết giá trị và tăng chuỗi giá trị

Chương 8: Tiếp nhận các biện pháp kỹ thuật tinh gọn

Chương 9: Sử dụng cách tiếp cận thử nghiệm để phát triển sản phẩm

Chương 10: Thực thi Yêu cầu Nhiệm vụ

PHẦN IV: CHUYỂN ĐỔI

Chương 11: Phát triển nền văn hóa đổi mới

Chương 12: Nắm chắc tư duy tinh gọn trong quản trị, quản lý rủi ro và tuân thủ (GRC)

Chương 13: Phát triển quản lý tài chính để thúc đẩy đổi mới sản phẩm

Chương 14: Biến IT thành một lợi thế cạnh tranh

Chương 15: Hãy bắt đầu với những gì bạn có

Lời giới thiệu cho Loạt sách Tinh gọn

Trong vài năm gần đây, LEAN hay TINH GỌN trong quản trị sản xuất và quản trị doanh nghiệp không còn là một thuật ngữ xa lạ.

Mọi tổ chức, doanh nghiệp hay mọi lĩnh vực kinh doanh từ sản xuất đến dịch vụ, thương mại đều muốn áp dụng triết lý, nguyên tắc và công cụ của phương pháp Tinh gọn vào các hoạt động quản trị để trở nên hiệu quả hơn và cạnh tranh hơn.

Loạt sách Tinh gọn do Eric Ries chủ biên bao gồm các cuốn: (i) Doanh nghiệp Tinh gọn, (ii) Vận hành Tinh gọn, (iii) Xây dựng Thương hiệu Tinh gọn, (iv) Phát triển Khách hàng Tinh gọn và (v) Phân tích Dữ liệu Tinh gọn. Với những nghiên cứu tỉ mỉ về triết lý Tinh gọn, nhóm tác giả đã mang đến cho độc giả những cách thức gần gũi và đơn giản nhất để có thể vận dụng triết lý Tinh gọn khởi nguồn từ những hoạt động sản xuất tại các nhà máy vào hầu hết những hoạt động kinh doanh của doanh nghiệp. Thông qua những bài học quản lý được các tác giả lồng ghép trong các cuốn sách, độc giả có thể thấy sức mạnh của việc áp dụng triết lý Tinh gọn tới thành công của mọi mặt trong kinh doanh.

Với cuốn Doanh nghiệp Tinh gọn, các bạn có thể nắm bắt được cách thức vận dụng triết lý Tinh gọn trên bình diện toàn bộ doanh nghiệp để cải tiến, đổi mới hoạt động sản xuất kinh doanh của doanh nghiệp từ quản trị chiến lược, quản trị tài chính, quản trị hoạt động tác nghiệp, quản lý danh mục đầu tư, đến quản lý rủi ro, tái cấu trúc bộ máy, hệ thống kinh doanh. Các tác giả đã cố gắng xây dựng một bộ khuôn mẫu và những nguyên tắc theo triết lý loại bỏ lãng phí của hệ thống, tập trung vào các quy trình mang lại giá trị gia tăng cho tổ chức hay doanh nghiệp. Từ đó, họ cũng nhấn mạnh rằng thách thức lớn nhất của việc cải tiến doanh nghiệp không nằm ở hệ thống công nghệ hay thiết bị mà nằm chủ yếu ở nhận thức đổi mới tư duy của con người trong tổ chức.

Ở một góc độ khác, cuốn Vận hành Tinh gọn tập trung vào việc giúp các doanh nghiệp sau khởi nghiệp có những bước đi tiếp theo tối ưu và hiệu quả nhất. Thông qua cuốn sách này, các bạn có thể nhận thấy rõ nét tư duy Đúng Thời Điểm (Just-In-Time) được áp dụng như thế nào trong việc triển khai vận hành trong một doanh nghiệp, nhất là những doanh nghiệp vẫn còn đang chập chững bước trên con đường kinh doanh mới của mình. Vận hành Tinh gọn chỉ ra những cách thức mà các doanh nghiệp còn non trẻ có thể áp dụng để triển khai các Kế hoạch Kinh doanh của mình chi tiết nhất với mục tiêu ít tốn kém nhất và hiệu quả cao nhất, đồng thời cũng giúp các doanh nghiệp mới loại bỏ được những rủi ro tiềm ẩn trong quá trình triển khai kế hoạch kinh doanh đầy thách thức này.

Cuốn sách Xây dựng Thương hiệu Tinh gọn lại tập trung đề cập đến việc ứng dụng triết lý Tinh gọn vào Xây dựng Thương hiệu ở các doanh nghiệp, nhất là các doanh nghiệp khởi nghiệp. Triết lý Tinh gọn được áp dụng khi các doanh nghiệp coi Thương hiệu cũng như là sản phẩm, luôn không hoàn hảo và cần phải đổi mới, cải tiến dần theo thời gian. Từ đó, thương hiệu của doanh nghiệp mới có thể in sâu trong tư duy của khách hàng hay đối tác. Xây dựng Thương hiệu Tinh gọn cho phép các doanh nghiệp dù không dư giả về tài chính vẫn có thể xây dựng và phát triển thương hiệu theo cách riêng của mình – xây dựng thương hiệu từ bên trong, từ nền tảng các giá trị cốt lõi – theo cách tiếp cận tránh lãng phí, chất lượng và hiệu quả cao.

Một cuốn sách về triết lý Tinh gọn khác trong loạt sách Tinh gọn cũng rất quan trọng với các bạn là Phát triển Khách hàng Tinh gọn. Với cuốn sách này, tác giả đã mang đến cho chúng ta câu trả lời tối ưu nhất về việc tìm hiểu mong muốn của khách hàng để phát triển những sản phẩm tốt nhất cho họ cũng như phát triển được các mối quan hệ bền vững với khách hàng dựa trên nền tảng tư duy đổi mới, cải tiến liên tục của triết lý Tinh gọn. Cuốn sách cũng mang đến cho các doanh nghiệp những công cụ phù hợp nhất để khám phá, thấu hiểu khách hàng hay cách thức tối ưu nhất để tiếp cận và tạo dựng niềm tin từ khách hàng, đặc biệt phù hợp đối với các doanh nghiệp khởi nghiệp.

Khác với các cuốn sách trên, cuốn Phân tích Dữ liệu Tinh gọn đề cập đến một khía cạnh rất quan trọng và cũng rất cụ thể của doanh nghiệp, đó là phân tích, đánh giá những dữ liệu kinh doanh để từ đó đưa ra các quyết định chính xác và phù hợp nhất, ĐÚNG THỜI ĐIỂM nhất. Triết lý Tinh gọn được áp dụng ở đây đưa độc giả đến việc gắn kết tư duy cải tiến, tư duy đúng thời điểm với các con số khô khan, những số liệu kế toán khó đọc nhưng lại hàm chứa những thông điệp then chốt của doanh nghiệp. Nếu các doanh nghiệp biết cách phân tích và sử dụng dữ liệu của họ một cách thông minh, không lãng phí, không dư thừa và đúng thời điểm thì lợi ích mà các dữ liệu này mang lại là vô cùng to lớn.

Loạt sách Tinh gọn sẽ giúp các bạn có thể thấy rõ hơn cách thức vận dụng triết lý Tinh gọn không chỉ cho một lĩnh vực hay một nhóm doanh nghiệp mà còn cho thấy triết lý Tinh gọn nếu thực sự được thấu hiểu và nắm vững thì có thể trở thành chìa khóa giúp doanh nghiệp, đặc biệt là doanh nghiệp khởi nghiệp hay còn non trẻ, thành công!

Nguyễn Danh Nguyên

Viện trưởng Viện Kinh tế & Quản lý, Đại học Bách Khoa Hà Nội

Lời tựa

Phần mềm đang nuốt chửng cả thế giới.

− MARC ANDREESEN

Trong một doanh nghiệp công nghiệp, việc tránh né phần mềm là một việc làm rất nguy hiểm... Một ngày nào đó, biết đâu sẽ có một công ty phần mềm sẽ hạ gục Tập đoàn GE¹, và tốt hơn hết, chúng ta nên biết lo dần đi.

¹. General Electric, Tập đoàn đa quốc gia của Mỹ hoạt động trong lĩnh vực năng lượng, công nghệ, cơ sở hạ tầng, vốn tài chính và tiêu dùng công nghiệp. (BTV)

− JEFF IMMELT

Bạn là một tên ngốc nếu chỉ làm theo lời tôi. Bạn sẽ còn ngốc hơn nữa nếu không làm như tôi bảo. Bạn phải tự suy nghĩ và tìm kiếm những ý tưởng tốt hơn tôi.

− TAI-ICHI OHNO

Trong cuốn sách này, chúng tôi trình bày cách phát triển tổ chức để có thể đổi mới và thích ứng nhanh với những thay đổi của thị trường, nhu cầu khách hàng và sự phát triển của công nghệ.

Các công ty tồn tại hay phá sản phụ thuộc vào khả năng phát hiện những lĩnh vực kinh doanh mới và liên tục tạo ra các giá trị cho khách hàng. Điều này đã luôn đúng, nhưng trong những năm gần đây nó chưa bao giờ đúng hơn thế. Áp lực cạnh tranh gia tăng và càng trở nên gay gắt hơn trong bối cảnh diễn ra những thay đổi nhanh chóng về công nghệ và xã hội. Chỉ số Shift Index2 của Deloitte cho thấy vòng đời trung bình của một công ty thuộc danh sách Fortune 500 đã giảm từ khoảng 75 năm cách đây một thế kỷ xuống còn 15 năm hiện nay. Giáo sư Richard Foster của Đại học Yale nhận định: “Tới năm 2020, hơn 3/4 trong danh sách S&P 500 sẽ là những công ty mà chúng ta chưa từng biết đến.” Sự tồn tại lâu dài của bất kỳ một doanh nghiệp nào cũng phụ thuộc vào khả năng am hiểu và khai thác các nguồn lực văn hóa và kỹ thuật để tiếp tục thúc đẩy các vòng cải tiến.

² Shift Index là chỉ số đo lường những xu hướng dài hạn trong môi trường kinh doanh tại Mỹ. (BTV)

Thứ nhất, Internet và truyền thông xã hội đã cung cấp cho khách hàng những công cụ quyền lực để ra quyết định. Những công cụ này cũng trao cho các tổ chức thông minh những cách thức mới để khám phá và kết nối với người dùng và khách hàng. Các doanh nghiệp biết sử dụng tư duy thiết kế và thiết kế trải nghiệm người dùng (UX) một cách có chiến lược để khiến khách hàng hài lòng trong từng hoạt động tương tác với tổ chức thường phát triển rất nhanh: Nghiên cứu cho thấy những công ty áp dụng thiết kế UX theo cách này tăng trưởng nhanh hơn và đạt doanh thu cao hơn.³

³ Evaluation of the Importance of Design (tạm dịch: Đánh giá về tầm quan trọng của thiết kế), Danish Design Center, 2006. (TG)

Thứ hai, những tiến bộ về công nghệ và phương thức sản xuất đã giúp con người có thể thiết lập, phát triển và loại bỏ những sản phẩm và dịch vụ lỗi thời một cách nhanh chóng với lượng vốn đầu tư ít ỏi. Nhiều nhóm trên thế giới đã sáng tạo ra những sản phẩm mới dựa vào phần mềm chỉ trong vài ngày hoặc vài tuần, sử dụng những dịch vụ và cơ sở hạ tầng miễn phí hoặc rất rẻ, và sau đó nhanh chóng phát triển thành những sản phẩm có khả năng thu hút khách hàng. Trong tương lai gần, sự phổ biến rộng rãi của các thiết bị kết nối mạng giá rẻ nhưng hiệu quả sẽ giúp chúng ta sáng tạo và phát triển nhiều hơn nữa các sản phẩm với chi phí thấp trong vòng quay ngắn tương tự. Khi in 3D rẻ hơn, nhanh hơn và bắt đầu sử dụng nhiều loại nguyên liệu hơn, chúng ta sẽ tạo ra và chuyển đến khách hàng một lượng khổng lồ các sản phẩm theo yêu cầu.

Phần mềm có ba đặc tính giúp tạo ra khả năng đổi mới nhanh chóng này. Thứ nhất, việc sáng tạo và phát triển ý tưởng bằng phần mềm có chi phí tương đối rẻ. Thứ hai, có thể sử dụng những sáng tạo đó ngay từ giai đoạn đầu phát triển sản phẩm. Cuối cùng, trong quá trình sáng tạo sản phẩm, có thể phát hiện ra phần lớn những yếu tố được khách hàng đề cao và đưa chúng trở lại thiết kế, làm gia tăng khả năng kiểm nghiệm ý tưởng mới với người dùng, thu thập ý kiến đánh giá và sử dụng chúng để cải tiến sản phẩm cũng như các hoạt động kinh doanh.

Trong khi đó, việc thu nhỏ không ngừng đã giúp những chiếc máy vi tính quyền lực, trong đó phần mềm đứng ở vị trí trung tâm, trở nên nhỏ xíu và kết nối được với mọi thứ. Trong một bài báo của Forbes có tựa đề “Now every company is a software company” (tạm dịch: Mọi công ty hiện nay đều là công ty phần mềm), David Zanca, Phó Chủ tịch Cao cấp phụ trách công nghệ thông tin (IT) tại FedEx, đã nói rằng mình đang quản lý “một công ty phần mềm bên trong FedEx”. Venkatesh Prasad, Giám đốc Kỹ thuật của Ford, thì mô tả công ty của mình là một nhà sản xuất “những bộ máy tính tinh vi biết chạy”. Ben Wood của CCS Insight lưu ý rằng Nokia “đã trải qua một thập kỷ đổi mới kinh ngạc về phần cứng, nhưng Apple thì nhận thấy rằng tất cả những gì bạn cần chỉ là một màn hình hình chữ nhật, phần còn lại thuộc về phần mềm.”⁴ Kết quả của bước chuyển tư duy về phần mềm là, các công ty, trong đó có những công ty tiên phong trong hoạt động thuê ngoài (outsource) IT như GE và GM, lại đưa việc phát triển phần mềm trở lại trong nước. Như chúng ta sẽ thảo luận tại Chương 15, chính quyền Anh cũng đang đi theo mô hình này. Một bài báo trên tờ The Economist viết:⁵

⁴ http://www.bbc.co.uk/news/technology-23947212; theo quan điểm của chúng tôi, đây là tầm nhìn chủ đạo đứng sau vụ mua lại Nokia của Microsoft.

5 The Economist Special Report: Outsourcing and Offshoring (tạm dịch: Báo cáo đặc biệt của tờ Economist: Thuê ngoài và thuê ngoài quốc tế), 406, no. 8819, 19/1/2013. (TG)

Lý do khiến GM làm việc này cũng có thể hiệu quả với nhiều công ty khác. “IT đã trở nên phổ biến hơn trong doanh nghiệp của chúng ta và giờ chúng ta coi đó là nguồn lực quan trọng để tạo ra lợi thế cạnh tranh,” Randy Mott, Giám đốc Thông tin của GM, người có trách nhiệm loại bỏ chiến lược thuê ngoài, đã nhận xét như vậy. Ông cho biết, mặc dù công việc được thuê ngoài, nhưng phần lớn các nguồn lực mà GM sử dụng cho IT đều phục vụ mục đích duy trì mọi việc theo hiện trạng thay vì tìm những cách làm mới. Công ty nhận ra rằng việc để lại phần lớn công việc IT ở trong nước hoặc ở các quốc gia lân cận sẽ giúp cho công ty tăng khả năng linh hoạt, tăng tốc độ và khuyến khích cải tiến nhiều hơn.

Giới kinh doanh đang chuyển từ việc coi IT là một tiện ích giúp cải thiện các hoạt động nội bộ sang tin tưởng rằng các chu trình đổi mới dựa trên phần mềm và công nghệ là một lợi thế cạnh tranh. Điều này dẫn đến những ảnh hưởng sâu rộng. Các chương trình và mô hình quản lý dự án truyền thống mà chúng ta dùng cho IT đã không còn phù hợp với các chu trình đổi mới nhanh chóng. Tuy nhiên, chúng gắn chặt vào cách mà chúng ta quản lý mọi thứ, từ vận hành và dịch vụ khách hàng đến lập ngân sách, quản lý và chiến lược. Những thành tố của một cấu trúc coi sản phẩm là trọng tâm và phù hợp với quy mô đã được chú ý trong 10 năm qua, nhưng chưa được kết nối và trình bày một cách hệ thống. Cuốn sách này đặt mục tiêu lấp đầy khoảng trống đó, tạo cảm hứng cho các tổ chức đã tiếp nhận thành công những ý tưởng này. Quan trọng hơn, chúng tôi đã tiến hành một cuộc điều tra chi tiết về văn hóa hiệu năng cao, yếu tố trọng yếu giúp đổi mới nhanh chóng và với quy mô phù hợp.

TẠI SAO CHÚNG TÔI VIẾT CUỐN SÁCH NÀY?

Tất cả các tác giả của cuốn sách đều có kinh nghiệm làm việc ở các công ty cũng như những doanh nghiệp khởi nghiệp, chúng tôi cùng nhau bắt tay vào việc mô tả một cách tiếp cận thực tế và có hệ thống đối với công cuộc cải tiến cũng như chuyển đổi một cách hiệu quả trong môi trường doanh nghiệp. Chúng tôi không chỉ đề cập cách các tổ chức có hiệu suất cao để phát triển sản phẩm mà còn trình bày cách giúp các công ty mong muốn có hiệu suất cao có thể tiếp nhận những kỹ thuật này thường xuyên với mức độ rủi ro thấp nhưng khả năng đạt lợi nhuận cao.

Chúng tôi viết cuốn sách này vì không đồng tình với hiện trạng của ngành công nghiệp phần mềm. Các kỹ thuật và biện pháp thực hành mà chúng tôi mô tả không mới và đã được nhiều người biết tới. Tuy nhiên, chúng chưa phải là trọng tâm, thường được thực hiện nhỏ lẻ và chỉ đem lại sự cải thiện cục bộ chứ không có tính hệ thống. Kết quả là, các công ty cứ chật vật tìm cách thiết kế – với chi phí khổng lồ – các sản phẩm, dịch vụ và hoạt động của mình mà vẫn không đem lại những giá trị mong muốn cho khách hàng.

Khi những cuốn sách Continuous Delivery (tạm dịch: Xây dựng phần mềm nhanh chóng) và The Lean Startup (Khởi nghiệp tinh gọn⁶) xuất bản, chúng tôi nhận thấy những người làm việc trong các doanh nghiệp có nhu cầu rất cao về việc tiếp nhận những biện pháp thực hành được mô tả trong đó. Rất nhiều công ty đã thu được lợi nhuận đáng kể từ việc sử dụng những biện pháp thực hành mà chúng tôi gợi ý để tạo ra các sản phẩm chất lượng cao hơn và đưa ra thị trường với tốc độ nhanh hơn. Điều này giúp giảm chi phí và rủi ro, đồng thời giúp các nhân viên vui vẻ hơn vì không phải làm việc mệt mỏi nhiều giờ liền trong khi doanh nghiệp có cơ hội khai thác khả năng sáng tạo và đam mê công việc của họ.

6 Độc giả có thể tìm mua bản tiếng Việt được Đinh Tị Books phát hành năm 2016. (BTV)

Tuy nhiên, người đọc có thể sẽ thấy khó áp dụng thành công những ý tưởng này. Trong nhiều trường hợp, người ta chỉ thấy sự cải thiện ở một bộ phận của tổ chức, trong khi bộ phận đó vẫn cần phải làm việc với phần còn lại của tổ chức, những nơi vẫn hoạt động theo phương pháp thuyền thống. Vì vậy, chúng tôi mô tả cách thức mà các công ty thành công đã suy tính lại mọi khâu, từ quản lý và quản lý tài chính đến quản lý rủi ro, điều hành hoạt động, kiến trúc hệ thống, lập chương trình, quản lý danh mục đầu tư và quản lý các yêu cầu trong quá trình tìm cách gia tăng triệt để tính hiệu quả của tổ chức.

Cuốn sách này trình bày một bộ khuôn mẫu và nguyên tắc được thiết kế nhằm giúp bạn thực thi những ý tưởng này. Vì tin rằng mọi tổ chức đều khác biệt và có những nhu cầu khác nhau nên chúng tôi không cung cấp những quy tắc thực thi các biện pháp cụ thể. Thay vào đó, chúng tôi đưa ra cách tự tìm tòi biện pháp thực thi, trong đó nhấn mạnh tầm quan trọng của việc thử nghiệm, qua đó học được cách giúp cho tổ chức của bạn thích nghi tốt nhất với những ý tưởng và sự cải tiến này. Các tiếp cận này mất nhiều thời gian hơn, nhưng có lợi thế vì sớm cho thấy những lợi ích có thể đo lường và giúp giảm rủi ro của việc thay đổi. Nó cũng giúp cho tổ chức và nhân viên của bạn có khả năng tự tìm hiểu những gì là hiệu quả nhất cho mình.

Chúng tôi hy vọng các bạn sẽ tìm thấy trong cuốn sách này những điều có giá trị. Phản ứng nguy hiểm nhất sẽ là: “Đó là những ý tưởng hay nhưng không phù hợp với tổ chức của chúng ta.” Như Taii- chi Ohno, cha đẻ của Hệ thống Sản xuất Toyota (Toyota Production System), đã nói:

Dù bạn là một nhà quản lý cấp cao nhất, cấp trung hay chỉ là công nhân mới bắt tay vào công việc, thì tất cả đều là con người, vì thế chúng ta có những nhận thức sai, luôn tin rằng cách mà chúng ta đang làm mọi việc lúc này là tốt nhất. Hoặc có thể bạn không nghĩ rằng đó là cách tốt nhất, nhưng bạn cứ làm và cho là “Chúng ta không thể dừng lại được, đây là cách mà mọi việc diễn ra.”

Bạn sẽ phải đối mặt với trở ngại khi muốn tiếp nhận những ý tưởng trong cuốn sách này. Khi đọc các ví dụ điển hình, có lẽ bạn sẽ thấy cách tiếp cận được mô tả ở đây không có ích trong tổ chức của bạn. Tuy nhiên, đừng biến những trở ngại đó thành sự phản đối. Hãy coi những gì đọc được ở đây là cảm hứng cho những nỗ lực của riêng bạn chứ không phải là những công thức nấu ăn mà bạn phải làm theo răm rắp. Hãy không ngừng tìm hiểu những trở ngại và coi chúng là cơ hội để thực nghiệm và học hỏi. Chúng tôi lại xin trích lời của Ohno:

Các cơ hội Kaizen (Cải tiến) là vô hạn. Đừng nghĩ rằng bạn đã làm việc tốt hơn trước và cảm thấy thỏa mãn... Điều đó tương tự như việc một sinh viên trở nên tự cao tự đại vì đã giành được phần thắng 2 trong số 3 phiên tranh luận với thầy của mình. Một khi bạn đã chấp nhận các ý tưởng kaizen, điều quan trọng là bạn phải hiểu rằng phía sau mỗi ý tưởng kaizen luôn có một ý tưởng khác.

Các cơ hội cải tiến có mặt ở khắp mọi nơi, không chỉ trong những sản phẩm hay dịch vụ chúng ta tạo ra mà còn trong cách chúng ta hành xử, tương tác và, quan trọng nhất, trong cách tư duy của chúng ta.

NHỮNG AI CẦN ĐỌC CUỐN SÁCH NÀY?

Chúng tôi viết cuốn sách này chủ yếu dành cho các nhà lãnh đạo và các nhà quản lý. Cuốn sách tập trung vào những nguyên tắc và khuôn mẫu có thể được áp dụng trong bất cứ lĩnh vực nào và bất kỳ loại tổ chức nào.

Độc giả mà chúng tôi nhắm đến gồm:

◆ Các nhà điều hành quan tâm đến chiến lược, năng lực lãnh đạo, văn hóa tổ chức và quản lý hiệu quả.

◆ Các giám đốc công nghệ trong lĩnh vực ứng dụng, lĩnh vực hạ tầng cơ sở và vận hành.

◆ Bất cứ ai đang làm việc về lập trình hoặc quản lý dự án, bao gồm cả các thành viên của PMO (Project Management Office

– Bộ phận Quản lý Dự án).

◆ Người làm công tác tài chính và kế toán hoặc trong lĩnh vực quản lý, tổ chức và thực hiện nhiệm vụ, những người tham gia vào việc phân phối sản phẩm.

◆ Các CMO (Chief Marketing Officer – Giám đốc Marketing Chuyên nghiệp), các nhà quản lý sản phẩm, những người tham gia vào việc thiết kế sản phẩm và dịch vụ liên quan đến phát triển phần mềm.

Bất kỳ ai tham gia các nhóm phân phối sản phẩm cũng sẽ thấy cuốn sách này có giá trị, nhưng bạn đừng kỳ vọng chúng tôi bàn luận sâu về các biện pháp kỹ thuật mẫu, ví dụ như cách thực hiện các cuộc kiểm thử chức năng bền vững hay triển khai tự động hóa hoặc quản lý cấu hình. Những chủ đề này sẽ được thảo luận sâu hơn trong cuốn Continuous Delivery (tạm dịch: Phân phối liên tục).

Cuốn sách này đặc biệt hướng đến những nhân viên làm việc trong các tổ chức vừa và lớn, những người hiểu rằng họ phải có tư duy khác về chiến lược, văn hóa, quản lý và cách thức quản lý sản phẩm và dịch vụ thì mới có thể thành công. Điều đó không phải để nói rằng các tổ chức nhỏ hơn sẽ không thấy cuốn sách này có ích, mà chỉ có nghĩa là một số nội dung có thể không phù hợp với họ trong giai đoạn phát triển hiện tại.

Chúng tôi muốn viết cuốn sách này thật ngắn gọn, chính xác và thực tế. Để làm được điều đó, chúng tôi quyết định không dành nhiều thời gian thảo luận các mô hình lý thuyết định hướng cho những nguyên tắc và quy trình thực tế mà chúng tôi mô tả. Thay vào đó, chúng tôi trình bày một số nguyên tắc căn bản để các bạn có thể hiểu nền tảng lý thuyết cơ bản, sau đó mô tả việc áp dụng các lý thuyết này trên thực tế. Chúng tôi cũng cung cấp tài liệu tham khảo dành cho các độc giả quan tâm và muốn tìm hiểu thêm.

Chúng tôi cũng cẩn trọng không hướng dẫn chi tiết các công cụ phần mềm cần sử dụng và cách sử dụng chúng. Có hai lý do cho việc này. Thứ nhất, chúng tôi cho rằng việc lựa chọn công cụ thực ra không phải là một quyết định quá quan trọng (miễn là bạn tránh dùng những công cụ kém hiệu quả). Nhiều tổ chức đang trong giai đoạn chuyển sang áp dụng các phương pháp linh hoạt lại dành quá nhiều thời gian để lựa chọn các công cụ với hy vọng tìm được phép màu để giải quyết những vấn đề căn bản của mình. Nhưng công thức thất bại phổ biến nhất cho những tổ chức như vậy là sự thiếu khả năng thay đổi văn hóa tổ chức chứ không phải là do không có các công cụ tốt. Thứ hai, thông tin về các công cụ và tiến trình cụ thể sẽ nhanh chóng lỗi thời. Có nhiều công cụ hay (bao gồm nhiều công cụ nguồn mở) và tài liệu hướng dẫn chiến lược nhằm giúp tổ chức của bạn thành công, bất kể bạn lựa chọn các công cụ nào.

TỔNG QUAN

Phần I giới thiệu chủ đề chính của cuốn sách, đó là văn hóa, chiến lược và chu trình đổi mới. Trong Phần II, chúng tôi thảo luận về cách tìm kiếm các ý tưởng thu thập dữ liệu mới, đánh giá những ý tưởng nào sẽ tạo ra giá trị hoặc có khả năng thu hút cần thiết và nhanh chóng. Phần III trao đổi về cách khai thác các ý tưởng có đủ các giá trị cần thiết được phát hiện trong giai đoạn tìm kiếm trước đó, đồng thời trình bày một cách tiếp cận có tính hệ thống nhằm cải tiến cách điều hành các chương trình làm việc lớn. Cuối cùng, Phần IV làm rõ cách mà các doanh nghiệp có thể xây dựng một môi trường nuôi dưỡng tinh thần học hỏi và chú trọng việc thử nghiệm, trong đó tập trung vào văn hóa, quản lý, quản lý tài chính, IT và chiến lược.

Các độc giả nên đọc Phần I, sau đó có thể lựa chọn tiếp tục với các chương mà mình cảm thấy thú vị. Tuy nhiên, cũng đáng để đọc Chương 3, Chương 6 và Chương 7 trước khi tiếp tục đến Phần IV bởi vì Phần IV được trình bày dựa trên các khái niệm được trình bày trong các chương đó.

Phần IĐỊNH HƯỚNG

Mục đích của một tổ chức là giúp cho những con người bình thường làm được những điều phi thường.

− PETER DRUCKER

Giá trị cổ đông là ý tưởng ngớ ngẩn nhất trên đời. (Đó là) kết quả, chứ không phải là chiến lược. Đội ngũ chủ chốt của bạn chính là nhân viên, khách hàng và sản phẩm của bạn.

− JACK WELCH

Chúng tôi xin bắt đầu bằng việc đưa ra định nghĩa về doanh nghiệp: “Là một hệ thống phức tạp và có khả năng thích ứng bao gồm những con người có chung mục đích.”Vì vậy, doanh nghiệp mà chúng tôi nhắc đến ở đây gồm tất cả các công ty tư nhân, tập đoàn phi lợi nhuận và doanh nghiệp nhà nước. Chúng tôi sẽ đi chi tiết hơn vào những hệ thống phức tạp và có khả năng thích ứng trong Chương 1. Tuy nhiên, ý tưởng về một mục đích chung mà tất cả các nhân viên cùng chia sẻ sẽ là điều quan trọng đối với thành công của một doanh nghiệp. Mục đích của một công ty khác với tuyên bố tầm nhìn (trong đó mô tả những gì mà tổ chức này hướng đến) và sứ mệnh (trong đó mô tả hoạt động của công ty). Graham Kenny, Giám đốc Quản lý của hãng tư vấn Strategic Factors, cho rằng mục đích của một tổ chức là những gì mà tổ chức làm cho người khác, “đặt các nhà lãnh đạo và nhân viên vào vị trí của khách hàng”. Ông dẫn ra ví dụ về công ty thực phẩm Kellogg (“Nuôi dưỡng các gia đình để họ có thể phát triển thịnh vượng”) và công ty bảo hiểm IAG (“Giúp mọi người quản lý rủi ro, đồng thời khắc phục khó khăn và tổn thất bất ngờ”). Chúng tôi nêu thêm một ví dụ yêu thích nữa của chúng tôi, công ty SpaceX, do Elon Musk thành lập năm 2002, để cách mạng hóa việc di chuyển trong không gian và cuối cùng giúp con người có thể sống trên các hành tinh khác.

Sáng tạo, cập nhật và truyền tải được mục đích của công ty là trách nhiệm của các nhà điều hành doanh nghiệp. Họ cũng có trách nhiệm xây dựng một chiến lược giúp công ty đạt được mục đích và xây dựng nền văn hóa cần thiết để giúp chiến lược đó thành công. Cả chiến lược và văn hóa sẽ phát triển để thích ứng với những thay đổi của môi trường, các nhà lãnh đạo có trách nhiệm định hướng sự phát triển này và đảm bảo rằng văn hóa và chiến lược hỗ trợ lẫn nhau nhằm đạt được mục tiêu của công ty. Nếu các nhà lãnh đạo làm tốt việc của mình, thì tổ chức đó có khả năng điều chỉnh, phát hiện và đáp ứng được những nhu cầu thay đổi của khách hàng trong khi vẫn trụ vững trước những diễn biến bất ngờ. Đó chính là đặc tính thể hiện khả năng quản lý hiệu quả.

Trong khuôn khổ các công ty, ý tưởng về một mục đích chung chứ không phải việc tối đa hóa lợi nhuận có vẻ kỳ quặc. Trong nhiều năm, châm ngôn thông thường mà lãnh đạo các công ty thường tập trung thực hiện là tối đa hóa giá trị cổ đông, và mục đích này được nhấn mạnh bằng việc trả thù lao cho các nhà điều hành bằng cổ phiếu. Tuy nhiên, những chiến lược này có một số thiếu sót. Chúng tạo ra xu hướng ưu tiên cho các kết quả ngắn hạn (ví dụ như lợi nhuận quý) nhưng lại gây tổn hại đến các ưu tiên lâu dài như phát triển khả năng của nhân viên và các mối quan hệ với khách hàng. Chúng cũng có xu hướng ngăn cản sự đổi mới khi tập trung vào các hành động chiến thuật để giảm chi phí trong ngắn hạn, gây hại cho những chiến lược rủi ro hơn nhưng có tiềm năng tạo ra lợi nhuận lớn hơn theo thời gian, đó là nghiên cứu và phát triển hoặc sáng tạo những sản phẩm và dịch vụ siêu đổi mới. Cuối cùng, chúng thường bỏ qua các giá trị vô hình, bao gồm khả năng của nhân viên và tài sản trí tuệ, cũng như những hệ quả bên ngoài như các tác động đến môi trường.

Các nghiên cứu đã chỉ ra rằng việc chỉ tập trung vào tối đa hóa lợi nhuận sẽ tạo ra nghịch lý là làm giảm tỷ lệ lợi nhuận trên đầu tư. Thay vào đó, các tổ chức thành công về lâu dài nhờ phát triển khả năng đổi mới và tiếp nhận chiến lược được Jack Welch đưa ra trong phần đề từ ở trên: Tập trung vào nhân viên, khách hàng và sản phẩm. Phần I của cuốn sách này trình bày cách thức để đạt được điều đó.

Chương 1Giới thiệu

Trong một hệ thống được thiết kế sai, những người giỏi có thể vô tình phạm phải những hành động gây nguy hại lớn cho người khác.

− BEN GOLDACRE

Vào ngày 1 tháng 4 năm 2010, nhà máy ô tô duy nhất của California là New United Motor Manufacturing, Inc. (NUMMI) đóng cửa.

NUMMI, được thành lập năm 1984, là đơn vị liên doanh giữa GM và Toyota. Cả hai công ty đều muốn hưởng lợi từ đối tác của mình.

Toyota muốn mở một nhà máy ở Mỹ để tránh lệnh hạn chế nhập khẩu của Quốc hội Mỹ trước tình trạng thị phần ô tô của các doanh nghiệp Mỹ tại Mỹ giảm không ngừng. Đối với GM, đây là cơ hội để học cách sản xuất những chiếc ô tô nhỏ nhưng lợi nhuận cao và nghiên cứu về Hệ thống Sản xuất Toyota (TPS), một hệ thống đã giúp các nhà sản xuất ô tô của Nhật Bản liên tục khẳng định chất lượng cao nhất trong ngành công nghiệp này với mức giá thấp hơn nhiều so với mức giá của các nhà sản xuất Mỹ.

Khi tìm trụ sở cho liên doanh này, GM chọn địa điểm là một nhà máy lắp ráp đã đóng cửa có tên Fremont. Fremont là một trong những nhà máy tệ hại nhất của GM xét về cả chất lượng xe cũng như mối quan hệ giữa các nhà lãnh đạo và nhân viên. Đến thời điểm nhà máy này đóng cửa năm 1981, các mối quan hệ lao động gần như đã hoàn toàn sụp đổ, công nhân uống rượu và đánh bạc khi làm việc.

Đáng ngạc nhiên là Toyota đã đồng ý với yêu cầu của Bruce Lee, nhà đàm phán đại diện cho Nghiệp đoàn Công nhân Ô tô (United Auto Workers – UAW) về việc thuê lại các lãnh đạo nghiệp đoàn này từ Nhà máy Lắp ráp Fremont để dẫn dắt lực lượng công nhân ở NUMMI. Các công nhân được gửi tới Thành phố Toyota (Toyota City) ở Nhật Bản để học về TPS. Trong vòng 3 tháng, nhà máy NUMMI đã bắt đầu sản xuất những chiếc xe ô tô có chất lượng gần như hoàn hảo – một số trong đó có chất lượng tốt nhất tại Mỹ, tương tự như những chiếc xe từ Nhật Bản – với chi phí thấp hơn nhiều so với chi phí của Nhà máy Lắp ráp Fremont. Lee đã đúng khi đánh cược rằng “chính hệ thống, chứ không phải con người, đã khiến cho tình hình trở nên tệ hại.”

Người ta đã viết nhiều về TPS, nhưng một chủ đề mà các công nhân từ Nhà máy Lắp ráp Fremont chuyển đến làm việc tại NUMMI thường nói là về làm việc nhóm. Cụm từ này nghe có vẻ nhàm chán, nhưng đó là một trải nghiệm tuyệt vời đối với nhiều công nhân UAW. TPS coi xây dựng chất lượng sản phẩm là ưu tiên cao nhất, vì vậy khi một vấn đề được phát hiện, nó phải được giải quyết ổn thỏa trong thời gian sớm nhất, và khi đó hệ thống phải được cải tiến để có thể kiểm tra và ngăn chặn điều tương tự xảy ra. Các công nhân và các nhà quản lý đã hợp tác để làm được điều này. Ngay khi phát hiện ra vấn đề, một công nhân có thể gọi cho giám đốc bằng việc kéo chiếc dây cảnh báo andon¹ nổi tiếng. Giám đốc sẽ đến ngay để kiểm tra và giải quyết vấn đề. Nếu vấn đề không thể giải quyết trong khoảng thời gian cho phép, công nhân đó có thể dừng dây chuyền sản xuất cho đến khi khắc phục xong. Sau đó, nhóm sẽ kiểm thử và thực thi các ý tưởng giúp ngăn chặn vấn đề xuất hiện trở lại.

¹ Andon là kiểu cảnh báo nổi tiếng, cho phép bất cứ công nhân nào cũng được dừng hệ thống nếu họ phát hiện ra lỗi bằng cách kéo một chiếc dây được treo ngay phía trên của dây chuyền sản xuất. (BTV)

Những ý tưởng này – cho rằng nhiệm vụ chính của các nhà quản lý là giúp các công nhân, còn công nhân thì có quyền dừng dây chuyền sản xuất và cần được tham gia vào việc quyết định cách thức cải tiến hệ thống – là những điều vô cùng mới mẻ với các công nhân UAW. John Shook, người Mỹ đầu tiên làm việc tại Thành phố Toyota, người đảm nhiệm việc huấn luyện các công nhân NUMMI, cho biết: “Họ đã hết sức sửng sốt khi học hỏi cách thức làm việc mới, trong đó mọi người thực sự làm việc cùng nhau với tinh thần hợp tác cao – như là các thành viên của một đội vậy.”

Cách làm việc trong TPS trái ngược hoàn toàn với thông lệ quản lý truyền thống của Mỹ và châu Âu, vốn dựa trên các nguyên tắc của Frederick Winslow Taylor, người đã nghĩ ra triết lý khoa học trong quản lý. Theo Taylor, nhiệm vụ quản lý là phải phân tích công việc và chia thành các nhiệm vụ riêng rẽ. Sau đó, những nhiệm vụ này sẽ được thực hiện bởi các công nhân có độ chuyên môn hóa cao, những người không cần hiểu gì khác ngoài cách thực hiện nhiệm vụ chuyên môn cụ thể của mình sao cho hiệu quả nhất. Về cơ bản, chủ nghĩa Taylor cho rằng tổ chức là những bộ máy cần phải được phân tích và nắm rõ bằng cách phân chia chúng thành những bộ phận khác nhau.

Trái lại, trọng tâm của TPS là tạo ra một nền văn hóa tin cậy, trong đó mọi người gắn kết với nhau nhằm sản xuất một sản phẩm chất lượng cao theo yêu cầu; nhân viên và lãnh đạo phối hợp ở nhiều chức năng để không ngừng cải tiến – và đôi khi là tái thiết kế hoàn toàn – hệ thống. Những ý tưởng này từ TPS – một nền văn hóa tin cậy lẫn nhau, tập trung vào việc không ngừng cải tiến (kaizen), được củng cố bởi sự gắn kết và quyền tự quyết ở tất cả các cấp – là điều rất quan trọng đối với việc xây dựng một tổ chức lớn có khả năng thích ứng nhanh chóng với các điều kiện thay đổi.

Một phần quan trọng trong thành công của TPS là tác động của nó đến công nhân. Chủ nghĩa Taylor coi công nhân là một bộ phận bình thường của hệ thống, được trả tiền để thực hiện càng nhanh càng tốt các hoạt động đã được lên kế hoạch. Ngược lại, TPS yêu cầu công nhân phải theo đuổi khả năng làm chủ thông qua quá trình cải tiến liên tục, gắn kết họ với một mục đích cao hơn – nâng cao hơn nữa chất lượng, giá trị và dịch vụ khách hàng – và tạo cho họ quyền tự chủ nhất định khi được phép thử nghiệm các ý tưởng cải tiến và thực thi những ý tưởng đã thử nghiệm thành công.

Các nghiên cứu trong nhiều thập kỷ đã chứng minh rằng chính những động lực bên trong này là yếu tố tạo ra khả năng làm việc cao nhất trong quá trình thực hiện những nhiệm vụ đòi hỏi tính sáng tạo và phương pháp thử-và-sai, vốn không thể chỉ dựa vào việc tuân thủ một quy tắc. Trên thực tế, các động lực bên ngoài như phần thưởng và đánh giá con người qua xem xét quá trình làm việc thực ra lại làm giảm khả năng làm việc trong những công việc bất quy tắc như thế. Rick Madrid, người làm việc tại nhà máy Fremont cả trước và trong thời kỳ NUMMI, nói rằng TPS “đã thay đổi cuộc sống của tôi từ trì trệ, chán nản – và như con trai tôi đã nói, nó làm thay đổi thái độ của tôi. Nó đã thay đổi tất cả mọi thứ của tôi theo hướng tốt hơn.” Trao cho mọi người niềm tự hào về công việc của mình chứ không phải là cố gắng khuyến khích họ bằng củ cà rốt và cây gậy là một thành tố quan trọng của văn hóa hiệu năng cao.

Mặc dù các nguyên tắc trung tâm của TPS có thể khá dễ hiểu nhưng lại rất khó thực hiện. Thực tế là GM đã hoàn toàn thất bại trong việc tiếp thu những gì họ đã đạt được tại NUMMI để tiếp tục áp dụng vào các nhà máy GM khác. Một trong số những trở ngại lớn nhất là sự thay đổi hệ thống phân cấp của tổ chức. TPS bỏ khái niệm thâm niên, tức là các công nhân nghiệp đoàn được sắp xếp công việc dựa vào thâm niên làm việc và những công việc tốt nhất sẽ được giao cho người có thâm niên cao nhất. Theo TPS, mọi người phải học cách làm tất cả các công việc cần thiết của mình và luân phiên làm những việc đó. TPS cũng gạt bỏ những biểu hiện và đặc quyền hữu hình của ban lãnh đạo. Không ai thắt cà-vạt khi đến nhà máy NUMMI – kể cả các nhà thầu – để nhấn mạnh rằng mọi người đều là một phần trong một nhóm.

Các nhà quản lý không nhận được những ưu đãi như vẫn thường được dành cho họ tại các nhà máy khác của GM, ví dụ như nhà ăn hay nơi đậu xe riêng.

Cuối cùng, những nỗ lực cải tiến chất lượng sẽ xung đột với các ranh giới tổ chức. Trong hệ thống TPS, các nhà cung cấp, kỹ sư và công nhân phối hợp để không ngừng cải tiến chất lượng của các bộ phận và nhằm chắc chắn rằng công nhân có đủ công cụ cần thiết để thực hiện nhiệm vụ của mình. Điều này có tác dụng tại NUMMI vì các kỹ sư của NUMMI là tại chỗ, còn các linh kiện thì do các nhà sản xuất Nhật Bản có mối quan hệ hợp tác với Toyota cung cấp. Trong dây chuyền của Mỹ, mọi thứ khác hẳn. Nếu các linh kiện đến các nhà máy lắp ráp của GM có chất lượng thấp hoặc không phù hợp thì cũng chẳng có cơ chế nào để giải quyết vấn đề.

Ernie Schaefer, một nhà quản lý thuộc nhà máy Van Nuys của GM – nơi cũng phải đối mặt với nhiều vấn đề tương tự như nhà máy Fremont – đã mô tả những khác biệt của NUMMI: “Bạn có thể thấy rất nhiều điều khác biệt. Nhưng một điều mà bạn không thấy là hệ thống hỗ trợ cho nhà máy NUMMI. Lúc đó tôi không nghĩ rằng có ai đó hiểu được bản chất to lớn của hệ thống này. General Motors là một kiểu tổ chức né tránh trách nhiệm, ‘đá bóng cho người khác’. Mỗi bộ phận của chúng tôi rất tách biệt. Bạn thiết kế chiếc xe đó, và bạn vứt nó cho các công nhân sản xuất, thế là xong.” Đây chính là di sản của cách quản lý kiểu Taylor. Hệ thống TPS tồn tại – và chỉ có thể thành công – bên trong một hệ sinh thái gồm văn hóa tổ chức, các mối quan hệ với nhà cung cấp, quản lý tài chính, nguồn nhân lực và việc quản lý được thiết kế phù hợp với triết lý của nó.

GM đã cố gắng thực hiện TPS tại Van Nuys nhưng thất bại. Các công nhân và các nhà quản lý chống lại những yêu cầu thay đổi về vị trí và thái độ bất chấp mối đe dọa phải đóng cửa nhà máy (điều đã xảy ra). Theo Larry Spiegel, một cựu nhân viên của NUMMI, người đã được cử tới Van Nuys để giúp xây dựng hệ thống TPS, thì mọi người ở nhà máy không tin vào những lời đe dọa phải đóng cửa: “Có quá nhiều người tin rằng họ không cần phải thay đổi.”

Sự thiếu khẩn trương này chính là một rào cản cho việc điều chỉnh của GM – và có lẽ là trở ngại lớn nhất cho sự thay đổi tổ chức nói chung. Chi nhánh GM tại Mỹ mất khoảng 15 năm mới có thể đưa ra quyết định rằng họ cần phải nghiêm túc ưu tiên thực hiện TPS và 10 năm tiếp theo để thực sự thực hiện nó. Đến lúc này thì bất kỳ lợi thế cạnh tranh nào mà lẽ ra họ đã giành được lại không còn nữa. GM phá sản và được Chính phủ Mỹ hỗ trợ năm 2009, thời điểm mà GM rút khỏi NUMMI. Toyota đóng cửa nhà máy NUMMI năm 2010.

Câu chuyện về NUMMI rất quan trọng bởi vì nó mô tả mối quan tâm chính của cuốn sách này – đó là phát triển một doanh nghiệp tinh gọn như Toyota – và nhiều trở ngại chung khác. Toyota luôn cởi mở về những gì họ đang làm, mở cửa đón các chuyến tham quan nhà máy, thậm chí là cho cả các đối thủ – một phần bởi họ biết rằng những gì giúp TPS hoạt động được không phải là các quy trình cụ thể mà là văn hóa. Nhiều người tập trung vào các quy trình và công cụ phổ biến của TPS, ví dụ như dây cảnh báo andon. Một phó chủ tịch của GM thậm chí còn lệnh cho một nhà quản lý chụp ảnh chi tiết từng khu vực nhà máy NUMMI để họ có thể sao chép một cách chính xác. Kết quả là họ có một nhà máy với những chiếc dây andon nhưng lại không có ai kéo chúng bởi các nhà quản lý (theo nguyên tắc động lực bên ngoài) chỉ quan tâm đến số lượng xe ô tô – với bất cứ chất lượng nào – được đưa ra khỏi dây chuyền.

MỘT DOANH NGHIỆP TINH GỌN TRƯỚC TIÊN PHẢI LÀ MỘT HỆ THỐNG NHÂN VĂN

Khi những thay đổi về xã hội và công nghệ trên thế giới gia tăng, cách tiếp cận tinh gọn mà Toyota đi tiên phong trở nên quan trọng hơn bao giờ hết vì nó đưa ra một chiến lược đã được chứng minh là có hiệu quả cho việc phát triển trong tình trạng bất trắc nhờ việc nắm lấy những cơ hội thay đổi. Chìa khóa để hiểu một doanh nghiệp tinh gọn là phải hiểu rằng trước hết nó là một hệ thống nhân văn. Mọi người thường tập trung vào các quy trình và công cụ cụ thể mà các đội ngũ đã tinh gọn và thích ứng sử dụng, ví dụ như phương pháp quản lý “bảng thông tin” (Kanban board), các cuộc họp đứng, lập trình đôi, v.v...

Tuy nhiên, chúng lại thường được coi là các trình tự hay “quy trình tốt nhất” mà không được xem xét về bản chất thực, tức là những biện pháp phản ứng có hiệu quả trong một bối cảnh cụ thể nhằm theo đuổi một mục đích cụ thể.

Trong một tổ chức có văn hóa cải tiến không ngừng, những biện pháp phản ứng này hình thành tự nhiên bên trong các đội nhóm và sau đó sẽ bị loại bỏ khi không còn giá trị. Chìa khóa để xây dựng một doanh nghiệp tinh gọn là tạo cho những người đang làm việc khả năng giải quyết các vấn đề của khách hàng theo cách gắn kết với chiến lược của tổ chức lớn. Để đạt được điều này, chúng ta dựa vào những người có thể đưa ra các quyết định cục bộ nhưng lại có ý nghĩa ở cấp độ chiến lược – điều này, ngược lại, dựa chủ yếu vào dòng thông tin, bao gồm cả các vòng phản hồi.

Nhà xã hội học Ron Westrum đã nghiên cứu rộng rãi về dòng thông tin, chủ yếu trong bối cảnh các tai nạn và sai lầm của con người trong ngành hàng không và y tế. Westrum nhận ra rằng sự an toàn trong các bối cảnh này có thể được tiên đoán thông qua văn hóa tổ chức. Từ đó, ông phát triển một “thể liên tục các văn hóa an toàn” với 3 loại sau:

◆ Các tổ chức ốm yếu với đặc điểm là chứa đầy những nỗi lo sợ và mối đe dọa. Mọi người thường giữ lại hoặc giấu giếm thông tin vì những lý do chính trị, hoặc bóp méo chúng để tôn vinh bản thân.

◆ Các tổ chức quan liêu thì có xu hướng bảo vệ các bộ phận của mình. Nhân viên trong các bộ phận muốn duy trì “khoảng trời riêng”, khăng khăng giữ các quy tắc của họ và nhìn chung là làm mọi việc theo kiểu của họ.

◆ Các tổ chức giàu sinh lực thì tập trung vào sứ mệnh. Làm thế nào để chúng ta đạt được mục đích? Mọi thứ khác đều xếp sau hiệu suất cao và làm những gì phải làm.

Những nền văn hóa này xử lý thông tin theo nhiều cách khác nhau. Westrum quan sát và nhận thấy rằng: “Môi trường cung cấp dòng thông tin tốt chắc chắn sẽ hỗ trợ và khuyến khích các kiểu ứng xử có tính hợp tác và hướng đến tăng cường hiệu quả, ví dụ như trong giải quyết các rắc rối, trong đổi mới và xây dựng kết nối giữa các bộ phận. Khi phát sinh vấn đề, các tổ chức quan liêu tìm kiếm sự công bằng, còn các tổ chức giàu sinh lực thì cố gắng tìm ra những vấn đề căn bản của hệ thống.” Những đặc điểm của các nền văn hóa khác nhau được thể hiện trong Bảng 1-1.

BẢNG 1-1. Cách xử lý thông tin của các tổ chức

Hệ thống phân loại của Westrum được nghiên cứu rộng rãi và có vẻ hấp dẫn đối với các nhân viên làm việc trong các tổ chức ốm yếu (hoặc thậm chí là quan liêu). Tuy nhiên, một số ý tưởng của nó chưa được học thuyết hóa.

Năm 2013, công ty PuppetLabs, hãng in IT Revolution Press và hãng tư vấn công nghệ ThoughtWorks tiến hành khảo sát 9.100 chuyên gia công nghệ trên toàn thế giới để đánh giá những gì đã làm nên thành công của các tổ chức có hiệu năng cao. Bản báo cáo Tình hình Phát triển và Vận hành năm 2014 (The 2014 State of DevOps Report) của họ dựa trên việc phân tích câu trả lời của những người làm việc trong nhiều ngành khác nhau như tài chính, viễn thông, bán lẻ, nhà nước, công nghệ, giáo dục và y tế. Kết quả nổi bật của cuộc điều tra cho thấy hiệu năng IT mạnh là một lợi thế cạnh tranh. Các phân tích cho thấy những doanh nghiệp có bộ phận IT hiệu năng cao có gấp đôi cơ hội gia tăng lợi nhuận, thị phần và các mục tiêu sản xuất.

Cuộc khảo sát cũng xem xét các yếu tố văn hóa ảnh hưởng đến hiệu năng của tổ chức, qua đó nhận thấy yếu tố quan trọng nhất là mức độ hài lòng của mọi người đối với công việc, tức là mức độ đồng ý với những ý kiến dưới đây (điều này rất giống với phản ứng của các công nhân NUMMI khi được tiếp cận với Hệ thống Sản xuất Toyota):

◆ Tôi cho rằng tổ chức này là nơi tuyệt vời để làm việc.

◆ Tôi có đủ công cụ và nguồn lực để làm tốt việc của mình.

◆ Tôi hài lòng với công việc của mình.

◆ Công việc của tôi giúp tôi phát huy các kỹ năng và năng lực của mình.

Việc mức độ hài lòng đối với công việc là dấu hiệu hàng đầu về hiệu năng của tổ chức cho thấy tầm quan trọng của các động cơ bên trong. Nhóm khảo sát muốn tìm hiểu xem liệu mô hình Westrum có phải là một công cụ tốt để dự báo hiệu năng làm việc của tổ chức hay không. Vì vậy, họ đề nghị người tham gia đánh giá văn hóa nhóm của họ theo các trục mô hình Westrum như được thể hiện trong Bảng 1-1 bằng cách yêu cầu họ ước định mức độ đồng ý với các ý kiến như “Trong nhóm của tôi, thất bại dẫn đến một cuộc khảo sát để tìm ra nguyên nhân.” Bằng cách đó, cuộc điều tra có thể đánh giá được văn hóa của các tổ chức.

Kết quả phân tích thống kê cho thấy văn hóa nhóm không chỉ gắn bó chặt chẽ với hiệu năng của tổ chức mà còn là dấu hiệu rõ ràng về sự hài lòng với công việc. Kết quả đó rất rõ ràng: Một nền văn hóa có sinh lực dồi dào và độ tin cậy cao không chỉ quan trọng đối với việc hình thành một môi trường làm việc an toàn mà còn tạo nền tảng cho việc xây dựng một tổ chức hiệu năng cao.

YÊU CẦU NHIỆM VỤ: SỰ THAY THẾ CHO MỆNH LỆNH VÀ KIỂM SOÁT

Một nền văn hóa tổ chức có tính tin cậy cao thường đối lập với những gì mà mọi người vẫn biết đến là “Mệnh lệnh và Kiểm soát”, đó là ý tưởng từ quản lý khoa học, theo đó những người phụ trách lập kế hoạch còn nhân viên thì thực hiện các kế hoạch đó. Đây vốn được coi là mô hình hoạt động của quân đội. Tuy nhiên trên thực tế, văn hóa mệnh lệnh và kiểm soát này đã không còn được ưa thích trong các hoạt động quân sự kể từ năm 1806 khi quân đội Phổ, một tổ chức điển hình cho mô hình dựa vào kế hoạch, bị các lực lượng phi tập trung hóa và có tính linh động cao của Napoleon đánh bại thảm hại. Napoleon sử dụng một loại chiến tranh được gọi là chiến tranh cơ động để đánh bại các đội quân lớn hơn và được huấn luyện tốt hơn. Trong chiến tranh cơ động, người ta giảm thiểu nhu cầu chiến đấu thực tế bằng cách ngăn chặn khả năng phối hợp tác chiến của kẻ địch thông qua các hoạt động gây sốc và bất ngờ. Thành tố chủ chốt trong chiến tranh cơ động là khả năng nghiên cứu, ra quyết định và hành động nhanh hơn kẻ địch, cũng là khả năng cho phép các doanh nghiệp khởi nghiệp gây trở ngại cho các doanh nghiệp khác.

Ba người đặc biệt quan trọng đối với việc tổ chức lại quân đội Phổ sau khi bị Napoleon đánh bại là Carl von Clausewitz, David Scharnhorst và Helmuth von Moltke. Những đóng góp của họ không chỉ làm thay đổi học thuyết quân sự; mà còn có ý nghĩa quan trọng đối với những người lãnh đạo và quản lý các tổ chức lớn. Họ đặc biệt ưa thích ý tưởng Auftragstaktik, hay gọi là Yêu cầu Nhiệm vụ − vấn đề mà chúng ta nghiên cứu ở đây. Yêu cầu Nhiệm vụ giúp thực hiện chiến tranh cơ động một cách hiệu quả với quy mô phù hợp. Đó là chìa khóa để tìm hiểu cách mà các doanh nghiệp hiện tại có thể cạnh tranh với các doanh nghiệp khởi nghiệp.

Sau thất bại cuối cùng của Napoleon, Tướng David Scharnhorst được cử làm Tổng Tham mưu trưởng của Bộ Tổng Tham mưu mới được thành lập của Phổ. Ông thành lập một ủy ban cải cách với nhiệm vụ phân tích tình hình và bắt tay vào thay đổi quân đội Phổ. Scharnhorst nhận thấy rằng các sỹ quan của Napoleon có quyền ra quyết định khi tình hình thực địa thay đổi mà không phải đợi chấp thuận thông qua chuỗi mệnh lệnh. Điều này cho phép họ thích ứng nhanh chóng với những thay đổi của tình hình.

Scharnhorst muốn phát triển khả năng tương tự một cách có hệ thống. Ông nhận thấy điều này đòi hỏi phải huấn luyện một lực lượng nòng cốt gồm các sỹ quan tham mưu thông minh và độc lập, những người có chung các giá trị và có thể hành động quyết đoán và độc lập trên các chiến trường nóng. Vì vậy, họ thành lập các trường quân sự để đào tạo sỹ quan tham mưu, những người lần đầu tiên được tiếp nhận từ mọi tầng lớp xã hội và dựa trên năng lực.

Năm 1857, Helmuth von Moltke, người nổi tiếng nhất với câu nói “chẳng có kế hoạch nào tồn tại được khi giáp mặt với kẻ thù”, được bổ nhiệm làm Tổng Tham mưu của quân đội Phổ. Cải cách chủ chốt của ông, dựa trên văn hóa quân sự do Scharnhost thiết lập, coi chiến lược quân sự là hàng loạt những lựa chọn rộng rãi được các sỹ quan xác định trước trận đấu. Năm 1860, ông ra chỉ thị về “Hướng dẫn cho tư lệnh các đơn vị lớn”, trong đó xác định cách lãnh đạo một tổ chức lớn trong điều kiện bất trắc.

Trong tài liệu này, von Moltke lưu ý rằng: “Trong chiến tranh, tình hình thay đổi rất nhanh và khó có khả năng thực thi đầy đủ một hướng dẫn dài với nhiều chi tiết”. Vì vậy, ông khuyến nghị “không ra lệnh khi không thực sự cần thiết, không lập kế hoạch cho những tình huống nào không thể lường trước được”. Thay vào đó, ông khuyên rằng: “Cấp chỉ huy càng cao thì mệnh lệnh càng phải ngắn gọn và khái quát. Cấp dưới cần bổ sung bất kỳ vấn đề cụ thể nào mà họ thấy cần thiết, còn chi tiết về việc thực thi thì dùng những chỉ thị bằng lời hoặc có lẽ là chỉ một mệnh lệnh thôi. Điều này đảm bảo mọi người có quyền tự do hành động và quyết định trong phạm vi thẩm quyền của mình... Quy tắc là một mệnh lệnh phải bao gồm tất cả, nhưng cũng chỉ là những gì mà cấp dưới không thể tự quyết định khi cần đạt được một mục đích cụ thể.”

Điều quan trọng là mệnh lệnh luôn bao gồm một nội dung mô tả ý định của họ gắn với mục đích của mệnh lệnh. Điều này cho phép cấp dưới đưa ra quyết định đúng khi xuất hiện cơ hội hoặc trở ngại khiến họ không thể tuân thủ chính xác mệnh lệnh gốc. Von Moltke lưu ý rằng “có nhiều tình huống trong đó sỹ quan phải hành động dựa trên nhận định cá nhân. Một sỹ quan cứ chờ mệnh lệnh vào những lúc mà không ai có thể ra lệnh thì thật ngu xuẩn. Nhưng nguyên tắc là chỉ khi hành động đúng với ý chí của cấp trên thì anh ta mới hoàn thành tốt nhất vai trò của mình.”

Những ý tưởng này hình thành nên nội dung cốt lõi cho học thuyết Auftragstaktik, hay còn gọi là Yêu cầu Nhiệm vụ. Triết lý này, khi kết hợp với việc xây dựng một đội ngũ sỹ quan tham mưu được huấn luyện một cách chuyên nghiệp và biết cách áp dụng học thuyết vào hoạt động, được nhiều đơn vị quân đội tinh nhuệ tiếp nhận, trong đó có Thủy quân Lục chiến Mỹ và gần đây hơn là NATO.

Lịch sử phát triển Auftragstaktik của quân đội Phổ được mô tả chi tiết hơn trong luận án của Stephen Bungay về chiến lược kinh doanh với tiêu đề The Art of Action (tạm dịch: Nghệ thuật hành động) (những câu trích ở trên được lấy từ nội dung của phần “Hướng dẫn cho tư lệnh các đơn vị lớn” thuộc luận án này.) Bungay phát triển một học thuyết về chiến lược định hướng với quy mô phù hợp dựa trên công trình của Scharnhorst, von Moltke và một vị tướng Phổ khác là Carl von Clausewitz. Khi mới 16 tuổi, Clausewitz đã chiến đấu chống lại Napoleon trong những trận chiến định mệnh ở Jena và Auerstadt.

Sau đó, ông phục vụ trong ủy ban cải cách của Scharnhorst và để lại cho chúng ta một kiệt tác còn dang dở, đó là cuốn On War (tạm dịch: Về chiến tranh). Trong tác phẩm này, ông giới thiệu khái niệm “Màn sương Chiến tranh” (fog of war), đó là tình trạng không rõ ràng căn bản mà chúng ta gặp phải khi tham gia vào một môi trường lớn và đang thay đổi nhanh chóng với hiểu biết chưa đầy đủ về hệ thống nói chung. Ông cũng giới thiệu ý tưởng về sự bất đồng ( friction), ngăn cản thực tế diễn ra theo cách thức lý tưởng. Sự bất đồng này thể hiện ở dạng thông tin không đầy đủ, hiệu ứng phụ không mong muốn, các yếu tố về con người như sai sót, hiểu nhầm và hàng loạt những diễn biến bất ngờ.

SỰ BẤT ĐỒNG VÀ HỆ THỐNG THÍCH ỨNG PHỨC TẠP

Khái niệm của Clausewitz về sự bất đồng là một phép ẩn dụ tuyệt vời để hiểu về cách phản ứng của các hệ thống thích ứng phức tạp như một doanh nghiệp (hoặc bất kỳ tổ chức nào của con người). Đặc điểm riêng của hệ thống thích ứng phức tạp thể hiện ở chỗ không thể hiểu được thái độ của hệ thống này ở cấp độ toàn thể bằng cách tiếp cận giản hóa luận khi phân tích các bộ phận thành tố của nó. Đúng hơn là nhiều tài sản và mô hình phản ứng của các hệ thống thích ứng phức tạp “nảy sinh” từ sự tương tác giữa các sự kiện và các thành tố ở nhiều cấp độ bên trong hệ thống. Trong trường hợp các hệ thống mở (ví dụ như các doanh nghiệp), chúng ta cũng phải xem xét sự tương tác với môi trường, trong đó có hành động của khách hàng và các đối thủ cạnh tranh cũng như những thay đổi lớn hơn về xã hội và công nghệ. Sự bất đồng rốt cuộc là hậu quả của điều kiện nhân lực, tức là thực tế rằng các tổ chức bao gồm những con người có tư duy khác nhau và thông tin hạn chế. Vì vậy sự bất đồng là không thể tránh khỏi.

Bungay lập luận rằng sự bất đồng tạo ra ba khoảng cách. Thứ nhất, một khoảng cách kiến thức xuất hiện khi chúng ta tham gia vào việc lập kế hoạch hoặc hành động do tình trạng không đầy đủ thông tin thiết yếu mà chúng ta phải kiểm soát, và nhu cầu của chúng ta về việc đưa ra các giả định và hiểu được thông tin đó. Thứ hai, một khoảng cách liên kết là kết quả của việc con người không thể làm việc như đã lên kế hoạch, có lẽ là do những xung đột về ưu tiên, sự nhầm lẫn hoặc đơn giản là ai đó quên mất hoặc bỏ qua một thành tố nào đó trong kế hoạch. Cuối cùng là có một khoảng cách hiệu quả do những thay đổi không thể lường trước trong môi trường hoạt động, có lẽ là do các yếu tố khác gây ra hoặc hiệu ứng phụ bất ngờ tạo ra những kết quả khác với những gì mà chúng ta mong đợi. Những khoảng cách này được thể hiện trong Hình 1-1.

HÌNH 1-1. Những khoảng cách của các hệ thống thích ứng phức tạp (từ cuốn The art of Action) của Stephen Bungay.

Sau đó, Bungay mô tả biện pháp quản lý khoa học mà các doanh nghiệp thường áp dụng, giải pháp thay thế theo đề xuất của học thuyết Aufragstaktik và hiểu biết của chính ông về Yêu cầu Nhiệm vụ khi áp dụng trong kinh doanh, điều mà ông coi là “chủ nghĩa cơ hội có định hướng” (directed opportunism). Những điều này được mô tả trong Bảng 1-2.

BẢNG 1-2. Ba khoảng cách và cách quản lý chúng

Điều quan trọng cần phải hiểu là khi làm việc trong một hệ thống thích ứng phức tạp, có sự bất đồng thống trị, thì giải pháp quản lý khoa học không thể có tác dụng. Trên thực tế, chúng còn làm cho mọi việc tồi tệ hơn. Việc xây dựng những kế hoạch chi tiết hơn càng làm trì hoãn việc nhận được thông tin phản hồi để chúng ta có thể biết nhận định nào của mình là không có giá trị. Những bộ quy tắc và sự kiểm soát phức tạp sẽ trừng phạt được người ngây thơ nhưng những người có tội lại biết cách né tránh, và tất cả những điều đó hủy hoại nhuệ khí, sức đổi mới và hoạt động của doanh nghiệp. Việc thu thập thông tin sẽ thất bại khi phải đối mặt với các tổ chức quan liêu và ốm yếu, những đơn vị thường tìm cách che giấu hoặc bóp méo thông tin để bảo vệ lợi ích của mình. Các tổ chức không thể thoát khỏi gọng kìm của cách quản lý khoa học là những mục tiêu hoàn hảo để những tổ chức biết cách phát triển nhanh với nguồn lực hợp lý tấn công và phá hủy.

HÌNH THÀNH LIÊN KẾT ĐÚNG MỨC THEO YÊU CẦU NHIỆM VỤ

Điều gây lo ngại nhất cho các lãnh đạo và các nhà quản lý làm việc trong một hệ thống thích ứng phức tạp là làm thế nào để giúp mọi người trong tổ chức đưa ra quyết định đúng – và hành động theo lợi ích cao nhất của tổ chức – khi mà họ không bao giờ có thể hiểu toàn bộ những hệ quả từ các quyết định của họ và khi mà những sự kiện thực tế thường bất ngờ so với kế hoạch?

Trong cuốn The principles of product development flow (tạm dịch: Những nguyên tắc dòng chảy phát triển sản phẩm), Donalo Teinertsen trình bày Nguyên tắc Sứ mệnh dựa trên học thuyết Yêu cầu Nhiệm vụ, trong đó “cụ thể hóa kịch bản kết thúc thành công chiến dịch, mục đích của nó và những căng thẳng tiềm ẩn dù nhỏ nhất.” Theo Yêu cầu Nhiệm vụ, chúng ta có thể tạo ra sự liên kết không chỉ bởi một kế hoạch chi tiết về cách đạt được mục đích mà còn bằng cách mô tả ý định nhiệm vụ của mình và giải thích được tại sao chúng ta lại đang tiếp tục thực hiện công việc.

Chìa khóa của Yêu cầu Nhiệm vụ là phải tạo ra liên kết và thiết lập khả năng tự chủ bằng cách xác định những điều kiện mục tiêu rõ ràng từ cấp cao trong khuôn khổ thời gian được thống nhất – khuôn khổ này có thể nhỏ hơn trong các điều kiện bất trắc hơn – và sau đó dành phần chi tiết về cách thức đạt được các điều kiện mục tiêu đó cho các nhóm. Cách tiếp cận này có thể áp dụng tới nhiều cấp độ khác nhau trong hệ thống phân cấp, với mỗi cấp độ lại giảm quy mô trong khi cung cấp bối cảnh rõ ràng hơn. Theo mạch của cuốn sách này, nguyên tắc này được áp dụng trong nhiều bối cảnh:

Quản lý ngân sách và tài chính

Thay vì một tiến trình ngân sách truyền thống đòi hỏi tất cả những chi tiêu cho năm sau phải được lên kế hoạch và bị giới hạn trong các đề án và kế hoạch kinh doanh chi tiết, chúng ta xác định các mục tiêu cấp cao thông qua tầm nhìn về con người, tổ chức, hoạt động, thị trường và tài chính, những vấn đề thường xuyên được nghiên cứu. Hình thức này có thể được áp dụng ở nhiều cấp độ với các nguồn lực được phân bổ linh hoạt khi cần và các chỉ số được xem xét thường xuyên.

Quản lý chương trình

Thay vì tạo ra những kế hoạch chi tiết, rõ ràng về công việc cần tiến hành và sau đó chia thành các nhiệm vụ nhỏ hơn để giao cho các nhóm, chúng ta chỉ cần làm rõ ở cấp độ tổng quan các mục tiêu hữu hình cho mỗi loại hoạt động. Sau đó, các nhóm sẽ bàn bạc để tìm ra cách thức đạt được những mục tiêu này, trong đó có sự phối hợp với các nhóm khác, không ngừng tích hợp và kiểm tra công việc của nhau để đảm bảo rằng họ sẽ đáp ứng các mục tiêu ở cấp độ tổng quan.

Cải thiện tiến trình

Nỗ lực để không ngừng cải tiến các tiến trình là yếu tố then chốt của TPS và là một công cụ đắc lực để biến đổi các tổ chức. Trong Chương 6, chúng tôi trình bày về phương pháp Kata Cải tiến, tập trung vào các vòng lặp, cụ thể hóa các mục tiêu chính cho các tiến trình và cung cấp cho những người vận hành chúng thời gian và nguồn lực để thực hiện các thử nghiệm cần thiết nhằm đáp ứng các mục tiêu trọng tâm cho vòng lặp tiếp theo.

Điều quan trọng là các tiến trình dựa trên nhiệm vụ này phải thay thế cho các tiến trình chỉ huy và kiểm soát chứ không phải chạy theo chúng. Điều này đòi hỏi mọi người phải cư xử và hành động theo những cách khác nhau và phải học hỏi các kỹ năng mới. Nó cũng đòi hỏi phải có sự thay đổi văn hóa bên trong tổ chức như chúng ta sẽ thảo luận trong Chương 11. Bàn luận về cách thức áp dụng Yêu cầu Nhiệm vụ vào kinh doanh, Stepen Bunray phản ánh một nền văn hóa tạo điều kiện cho Yêu cầu Nhiệm vụ – điều mà, không hề tình cờ, có cùng những đặc điểm mà chúng ta nhận thấy trong các tổ chức giàu sinh lực được Westrum miêu tả trong Bảng 1-1:

Cốt lõi của sự thay đổi này là một cách tiếp cận tổng thể tác động đến việc tuyển dụng, huấn luyện, lập kế hoạch và kiểm soát các tiến trình và cả văn hóa cũng như các giá trị của một tổ chức. Yêu cầu Nhiệm vụ là khái niệm về khả năng lãnh đạo đặt con người vào vị trí trung tâm. Nó cũng phụ thuộc nhiều vào các yếu tố không xuất hiện trên bảng cân đối tài sản của một tổ chức như: Sự sẵn sàng nhận trách nhiệm của nhân viên; sự sẵn sàng của cấp trên trong việc ủng hộ các quyết định của nhân viên; sự bao dung đối với những sai lầm do thiện ý mà ra. Được thiết kế cho một môi trường bên ngoài khó lường và đầy thù địch, nó được xây dựng dựa trên một môi trường bên trong dễ đoán định và đầy thiện cảm. Trung tâm của cách tiếp cận này là một mạng lưới tín nhiệm ràng buộc mọi người trong hệ thống phân cấp từ trên xuống dưới, từ dưới lên trên và trong cùng một bậc. Để đạt được và duy trì điều đó, chúng ta cần nỗ lực không ngừng.

NHÂN VIÊN CHÍNH LÀ LỢI THẾ CẠNH TRANH CỦA BẠN

Câu chuyện về nhà máy Fremont không dừng lại với NUMMI. Trên thực tế, nơi này chính là địa điểm diễn ra hai quá trình chuyển đổi mô hình trong ngành công nghiệp sản xuất ô tô của Mỹ. Vào năm 2010, Tesla Motors mua NUMMI và đổi tên thành Tesla Factory (Nhà máy Tesla). Tesla liên tiếp áp dụng nhiều biện pháp đổi mới nhanh hơn Toyota, bỏ qua khái niệm “đời xe” để cập nhật thường xuyên hơn, và trong nhiều trường hợp, cho phép chủ những chiếc xe cũ tải xuống các vi chương trình mới (firmware) để tiếp cận các tính năng mới. Tesla cũng đi đầu trong việc minh bạch thông tin, công bố rằng công ty sẽ không thúc ép quá trình sáng chế. Qua đó, công ty lặp lại câu chuyện của Toyota khi còn sản xuất các máy dệt tự động. Người ta được biết là khi nghe tin các kế hoạch sản xuất một chiếc máy dệt bị đánh cắp, Kiichiro Toyoda nhận xét:

Chắc chắn là những tên trộm đó có thể làm theo các thiết kế và sản xuất ra được một chiếc máy dệt. Nhưng chúng ta đang nâng cấp và cải tiến những chiếc máy dệt của mình mỗi ngày. Vì thế, đến khi bọn trộm sản xuất được một chiếc máy dệt từ những kế hoạch bị đánh cắp thì chúng ta đã vượt xa điểm đó. Và bởi vì không có khả năng rút kinh nghiệm từ những thất bại khi sản xuất sản phẩm gốc, nên họ sẽ tốn thời gian hơn chúng ta rất nhiều khi muốn cải tiến chiếc máy dệt của họ. Chúng ta không cần lo lắng nhiều về điều đã xảy ra. Chúng ta chỉ cần tiếp tục hoạt động như trước đây, tức là không ngừng cải tiến mà thôi.

Giá trị lâu dài của một doanh nghiệp không nằm ở giá trị các sản phẩm và tài sản trí tuệ mà ở khả năng không ngừng gia tăng các giá trị mà doanh nghiệp cung cấp cho khách hàng – và thu hút thêm những khách hàng mới – thông qua việc cải tiến.

Một giả thiết chủ chốt của cuốn sách này – được minh chứng qua kinh nghiệm của các công ty như Tesla cùng với nhiều công ty khác – đó là tính linh hoạt được cung cấp bởi phần mềm có thể đẩy nhanh vòng cải tiến khi được thúc đẩy đúng cách. Phần mềm có thể cho doanh nghiệp của bạn lợi thế cạnh tranh bằng cách giúp bạn tìm kiếm những cơ hội mới và tranh thủ những cơ hội phù hợp một cách nhanh chóng hơn đối thủ cạnh tranh. Tin tốt là những khả năng này nằm trong tầm với của tất cả các doanh nghiệp chứ không chỉ những gã khổng lồ công nghệ. Dữ liệu trong Báo cáo Tình hình Phát triển và Vận hành năm 2014 cho thấy 10% trong số các tổ chức có hơn 10.000 nhân viên nằm trong nhóm tổ chức hiệu năng cao. Con số này thấp hơn tỷ lệ của các công ty nhỏ, nhưng vẫn rất ý nghĩa.

Nhiều nhân viên thuộc các doanh nghiệp tin rằng có sự khác biệt quan trọng nào đó giữa họ với Google, Amazon hay Netflix, những gã khổng lồ công nghệ vốn được coi là ví dụ về “sự đúng đắn” của công nghệ. Chúng ta thường nghe nói rằng “làm thế ở đây không hiệu quả đâu”. Điều đó có thể đúng, nhưng mọi người thường không tìm ra được những trở ngại trong tiến trình cải tiến của họ. Những người hoài nghi thường coi quy mô, luật lệ, tính phức tạp ước định, công nghệ truyền thống hoặc một vài đặc tính khác trong phạm vi họ hoạt động là rào cản cho sự thay đổi. Mục đích của chương này là để chứng tỏ rằng mặc dù những trở ngại này thực sự mang tính thách thức, nhưng người ta thấy rằng rào cản nghiêm trọng nhất lại nằm ở văn hóa, khả năng lãnh đạo và chiến lược của tổ chức.

Nhiều tổ chức đã cố gắng đi tắt để đạt hiệu quả cao hơn bằng cách đầu tư xây dựng các phòng thử nghiệm đổi mới sáng tạo, thâu tóm các doanh nghiệp khởi nghiệp, tiếp nhận các phương pháp hoặc tái tổ chức. Nhưng những nỗ lực như vậy vừa không cần thiết vừa không đủ. Chúng chỉ có thể thành công nếu kết hợp với các nỗ lực xây dựng một nền văn hóa và chiến lược sáng tạo trong toàn bộ tổ chức, bao gồm cả các nhà cung cấp, và nếu điều này đạt được thì lại không cần đến những bước đi tắt như thế.

Chương 2 của cuốn sách mô tả những nguyên tắc giúp các tổ chức thành công về lâu dài bằng cách cân bằng danh mục sản phẩm của họ. Đặc biệt, chúng ta phân biệt hai loại hoạt động độc lập trong vòng phát triển sản phẩm: Khám phá những ý tưởng mới để thu thập thông tin và loại bỏ những gì sẽ không được người dùng nhanh chóng tiếp nhận, và khai thác những gì mà chúng ta đã thẩm định là phù hợp với thị trường. Phần II của cuốn sách thảo luận cách điều hành giai đoạn khám phá, còn Phần III thì trình bày về giai đoạn khai thác. Cuối cùng, Phần IV cho thấy cách thức chuyển đổi tổ chức của bạn, trong đó tập trung vào thay đổi văn hóa, quản lý tài chính, quản lý, rủi ro và sự tuân thủ.

Chương 2Quản lý tính năng động của Hồ sơ Doanh nghiệp

Mục đích của một giao dịch là tạo ra một khách hàng.

− PETER DRUCKER

Trong chương này chúng ta sẽ xem xét vòng đời của doanh nghiệp và cách mà họ có thể sử dụng để cân bằng việc khám phá những mô hình kinh doanh mới với việc khai thác những mô hình đã được kiểm chứng. Chúng ta sẽ cần nắm được sự khác biệt này để hiểu khi nào thì các biện pháp và nguyên tắc khởi nghiệp có thể áp dụng trong điều kiện của doanh nghiệp và làm thế nào để chúng có thể sử dụng làm cơ sở quản lý hồ sơ cải tiến.

Trong cuốn Diffusion of Innovations (tạm dịch: Nhân rộng những đổi mới), Everett Rogers mô tả vòng phát triển của các công nghệ và ý tưởng thành công, như được thể hiện trong Hình 2-1. Theo thời gian, tất cả các ý tưởng thành công, bất kể là công nghệ, sản phẩm, mô hình kinh doanh hoặc thậm chí là các phương pháp, đều được phát triển từ tình trạng rất khan hiếm và không được phân phối công bằng thành một sản phẩm thương mại. Quá trình đó giúp hình thành nền tảng vững chắc để tạo ra những cải tiến mới, cao cấp hơn và có giá trị hơn. Dĩ nhiên, thời gian để các sáng kiến phát triển qua các giai đoạn khác nhau của vòng đời có thể rất khác nhau.

HÌNH 2-1. Đường cong chữ S thể hiện vòng đời của các sáng kiến

Rogers tin rằng có thể phân loại con người thành các nhóm dựa trên cách mà họ phản ứng với sự đổi mới, như được thể hiện trên Hình 2-2. Ban đầu, các công nghệ và ý tưởng mới được các nhà cải cách, nhóm nhỏ nhất trong tổng dân số, thực nghiệm. Những công nghệ này sẽ được nhóm người tiếp nhận đầu tiên sử dụng khi họ phát hiện chúng cung cấp lợi thế cạnh tranh. Theo cách này, thành công trong mỗi nhóm lại dẫn đến sự truyền bá rộng rãi hơn qua các nhóm khác. Các ý tưởng của Roger được phổ biến và xây dựng bởi Geoffrey Moore, người giới thiệu khái niệm “sự cách biệt (chasm)”, tức là một khoảng cách lô-gic giữa việc áp dụng của nhóm tiếp nhận đầu tiên với nhóm đa số đầu tiên. Ý tưởng về sự cách biệt này được củng cố khi Moore quan sát và nhận thấy rằng nhiều ý tưởng cải cách mới gặp khó khăn khi chúng được những người khôn ngoan coi là nguồn cung cấp lợi thế cạnh tranh nhưng chưa đủ vững vàng để được coi là một vụ cá cược an toàn hoặc chưa được những người trong nhóm đa số đầu tiên coi là biện pháp đã được chứng minh.

HÌNH 2.2. Vòng tiếp nhận công nghệ (từ cuốn Dealing with Darwin) của Geoffrey A. Moore, 2006

Sau khi thị trường đã tiếp thu một công nghệ hay ý tưởng mới có tính đột phá, hàng loạt dịch vụ sản phẩm sẽ ra đời. Lập luận của Moore về vòng đời sản phẩm được thể hiện trong Hình 2-3. Một dòng sản phẩm thành công ban đầu sẽ có tốc độ tăng trưởng cao (giai đoạn B), sau đó là một thị trường được củng cố ở giai đoạn trưởng thành (giai đoạn C). Đặc thù của việc tăng trưởng trong các thị trường trưởng thành được xác định bằng việc thâu tóm đối thủ và các khách hàng mới cũng như tính hiệu quả. Cuối cùng, các dòng sản phẩm đó bước vào giai đoạn thoái trào (giai đoạn D). Ở bất kỳ giai đoạn nào, một dòng sản phẩm đều có thể bị một sáng kiến mới nào đó làm sụp đổ. Trên thực tế, một sáng kiến đổi mới được coi là có tính “phá hoại” do những tác hại của nó đối với các dòng sản phẩm và các mô hình kinh doanh hiện hành. Bất chấp tính phá hoại này, đôi khi sự đổi mới đó có thể giúp duy trì một thị trường sinh lời hạn chế; ví dụ, dòng điện thoại cơ bản vẫn là một loại hàng hóa quan trọng ở nhiều nước, và IBM vẫn kinh doanh các loại máy tính lớn một cách hiệu quả.

Hình 2-3.Vòng phát triển của các dòng sản phẩm (từ cuốn Dealing with Darwin) của Geoffrey A. Moore, 2006

Điểm đầu tiên cần chú ý là trên thực tế, cách quản lý, phát triển, tiếp thị và tài trợ các sản phẩm rất khác nhau ở các giai đoạn tăng trưởng khác nhau. Ví dụ, trong một thị trường trưởng thành, chúng ta hiểu rõ về khách hàng và giá trị mà họ nhận được từ sản phẩm; hiểu rõ cách thu hút khách hàng mới hay cách bán sản phẩm mới cho các khách hàng hiện tại; các sản phẩm mới trong một dòng thường chỉ bao gồm những đổi mới tăng dần (incremental innovations¹). Điều này sẽ ngược lại với những dòng sản phẩm mới.

¹ Incremental innovation là đổi mới tăng dần hay còn gọi là đổi mới liên tục, nhằm cải tiến sản phẩm và quy trình để duy trì vị thế cạnh tranh của doanh nghiệp trên thị trường hiện có. (BTV)

Mặc dù có nhiều chi tiết cần quan tâm ở những giai đoạn khác nhau của vòng đời sản phẩm, nhưng chúng ta có thể đi đến những cuộc thảo luận quan trọng bằng cách đơn giản hóa vấn đề và đặt trọng tâm vào hai hoạt động then chốt mà tất cả các doanh nghiệp đều thực hiện, đó là khám phá những loại sản phẩm và mô hình kinh doanh mới, và khai thác những sản phẩm và mô hình kinh doanh đã được chứng minh. Steve Blank coi đó là hoạt động “tìm kiếm” và “thực thi” trong quá trình phát triển khách hàng.

Các doanh nghiệp khởi nghiệp bắt đầu bằng việc khám phá những cơ hội mới thông qua cải tiến mô hình kinh doanh: họ tìm kiếm một mô hình kinh doanh mới gắn với mục đích và tầm nhìn của nhà sáng lập, đem đến giá trị cho khách hàng đồng thời có thể tạo ra lợi nhuận và sự tăng trưởng cho tổ chức. Sau khi doanh nghiệp được thành lập, mô hình kinh doanh đó sẽ được khai thác bằng việc phát triển và gọt giũa nó, tìm cách giảm chi phí, cải thiện tính hiệu quả và tăng thị phần và cơ sở khách hàng. Tuy nhiên, mọi mô hình kinh doanh đều chỉ là nhất thời: Cuối cùng, chúng và các dòng sản phẩm đều sẽ bị các dòng mới đánh sập. Vấn đề chỉ là thời gian.

Khám phá các cơ hội mới và khai thác các cơ hội hiện có là những chiến lược khác biệt căn bản đòi hỏi phải có cấu trúc, năng lực, tiến trình và tư duy khác nhau. Dù rất khó nhưng cũng cần nhấn mạnh đặc điểm quan trọng này: Các biện pháp quản lý có hiệu quả trong tiến trình khám phá sẽ dẫn tới thất bại nếu được áp dụng cho tiến trình khai thác các cơ hội mới và ngược lại. Những sự khác biệt giữa hai tiến trình này được phân tích trong Bảng 2-1.

Bảng 2-1. Khám phá và khai thác

Các doanh nghiệp khởi nghiệp phát hiện một mô hình kinh doanh thành công và vượt ra khỏi sự cách biệt sẽ thấy khó chuyển sang giai đoạn tiếp theo: Điều hành và phát triển trong một thị trường tăng trưởng. Trong khi đó, các tổ chức tự biến mình thành các công cụ điều hành thường mất đi khả năng khám phá những mô hình kinh doanh mới. Eric Ries tự nhắn nhủ bản thân về bước chuyển đổi tư duy này như sau:

Eric thân mến, cảm ơn ông đã phục vụ công ty này. Không may là công việc mà ông đang làm hiện không còn nữa, và công ty mà ông thường làm việc cùng không còn tồn tại. Tuy nhiên, chúng tôi rất vui được đề xuất cho ông một công việc mới tại một công ty mới hoàn toàn gồm tất cả các nhân viên trước đây. Công việc mới này đã bắt đầu cách đây nhiều tháng, và ông đang thất bại với nó. Thật may là tất cả những chiến lược ông đã phát triển và giúp ông thành công ở công ty cũ đều đã lỗi thời. Chúc may mắn!

Một mục tiêu then chốt của việc quản lý danh mục đầu tư thành công trong một doanh nghiệp là hiểu được cách cân bằng giữa việc khám phá các loại hình kinh doanh mới với việc khai thác các mô hình kinh doanh hiện thời đã được chứng minh là có hiệu quả – và cách thực hiện thành công việc chuyển đổi kinh doanh từ trạng thái này sang trạng thái khác. Các nhà lãnh đạo phải hiểu sự khác biệt giữa hai tiến trình này và có thể thực thi những quan điểm và chiến lược khác biệt hoàn toàn với những gì vốn chi phối họ.

KHÁM PHÁ CÁC Ý TƯỞNG MỚI

Chưa đến 50% số doanh nghiệp khởi nghiệp còn tồn tại sau 5 năm kể từ khi thành lập. Tương tự, các doanh nghiệp cũng lãng phí những khoản tiền khổng lồ để cố gắng phát triển các doanh nghiệp mới nhưng lại tạo ra rất ít giá trị cho khách hàng. Dĩ nhiên là bạn không thể biết trước liệu một doanh nghiệp mới sẽ thành công hay không, nhưng cuốn The Lean Startups (Khởi nghiệp tinh gọn) của Eric Ries đã mô tả chi tiết một phương pháp làm việc trong điều kiện vô cùng bất trắc. Phương pháp Khởi nghiệp Tinh gọn áp dụng trong môi trường doanh nghiệp cũng tương tự như trong thế giới các doanh nghiệp khởi nghiệp, miễn là chúng ta hiểu rõ mục đích của nó, rằng để phát hiện và thực thi những mô hình kinh doanh siêu đổi mới và nhanh chóng loại bỏ những mô hình đó nếu chúng hoạt động không hiệu quả.

Mọi lãnh đạo, bất kể làm việc trong một doanh nghiệp khởi nghiệp hay một doanh nghiệp trưởng thành, đều có tầm nhìn về doanh nghiệp của mình và giá trị mà nó đem lại cho phần đông khách hàng trung thành và thân thiết. Để tầm nhìn này trở thành sự thật, có hai giả định chính phải được đánh giá, đó là giả thiết giá trị và giả thiết tăng trưởng. Giả thiết giá trị đặt câu hỏi liệu doanh nghiệp có thực sự cung cấp giá trị cho khách hàng bằng việc giải quyết một vấn đề thực tế không. Nếu có, chúng ta có thể tin rằng đã tìm được sự hòa hợp giữa giải pháp và vấn đề (problem/solution fit). Giả thiết tăng trưởng nghiên cứu tốc độ thu hút khách hàng mới và đánh giá xem liệu doanh nghiệp có làm được những gì mà Steve Blank gọi là một tiến trình bán hàng liên tục gia tăng không – tức là liệu cơ sở khách hàng của doanh nghiệp có thể tăng theo kiểu “một cây gậy khúc côn cầu” trong Hình 2-1 hay không, và liệu chi phí thu hút khách hàng của chúng ta có hợp lý hay không. Nếu vượt qua được các thử nghiệm này, chúng ta sẽ có được sự hòa hợp giữa sản phẩm và thị trường (product/market fit) và có thể tiến tới hai giai đoạn cuối cùng trong tiến trình phát triển khách hàng của Steve Blank: Kiến tạo khách hàng, tức là chính thức phát triển kinh doanh, và sau đó xây dựng công ty, tức giai đoạn nỗ lực vượt qua sự cách biệt.

Trong phương pháp Khởi nghiệp Tinh gọn, chúng ta tiếp cận hệ thống bằng cách liên tục thực hiện các tiến trình này. Chúng ta bắt đầu bằng việc tìm ra những gì cần hiểu nhờ ây dựng một giả thiết giá trị; sau đó ra quyết định phải đo lường điều gì để có thể đánh giá đúng về giả thiết đó. Tiếp theo, chúng ta tiến hành một cuộc thử nghiệm đối với sản phẩm khả thi tối thiểu (minimum viable product), sản phẩm mà chúng ta tạo ra để thu thập những thông tin cần thiết từ khách hàng thực và nhận định đúng về việc chúng ta có được sản phẩm phù hợp với thị trường hay chưa.

Bí quyết ở đây là chỉ đầu tư một khối lượng công việc tối thiểu để hoàn thành quy trình này. Do hoạt động trong những điều kiện vô cùng bất trắc, chúng ta cần sẵn sàng cho trường hợp giả thiết giá trị của mình không đúng. Khi đó, chúng ta chuyển hướng, tiến đến một giả thiết giá trị mới dựa vào những gì đã nắm được và tái thực hiện tiến trình này. Chúng ta tiếp tục làm như vậy cho đến khi hoặc là đạt được sự hòa hợp giữa sản phẩm và thị trường, quyết định dừng thử nghiệm, hoặc là kiệt vốn. Lượng thời gian mà chúng ta có trước khi hết tiền được gọi là chặng đường phát triển ý tưởng khởi nghiệp (runway), và mục đích là để chuyến hướng nhiều nhất có thể nhằm tìm ra sự hòa hợp giữa sản phẩm và thị trường khi mà chúng ta vẫn ở trên chặng đường đó.

Một đặc điểm quan trọng của phương pháp Khởi nghiệp Tinh gọn là việc thực hiện các thử nghiệm rẻ và nhanh hơn so với xây dựng một sản phẩm hoàn chỉnh. Nhìn chung, chúng ta có thể xây dựng một sản phẩm khả thi tối thiểu và thu thập thông tin theo giờ, theo ngày hoặc theo tuần chứ không phải theo tháng hay theo năm, và sử dụng những nhóm nhỏ các nhân viên liên chức năng để tập trung thực hiện chu trình tiếp nhận phản hồi theo các bước xây dựng-đánh giá-học hỏi như được thể hiện trong Hình 2-4. Chúng ta hiểu rằng nhiều thử nghiệm sẽ thất bại nhưng một số sẽ thành công; tuy nhiên, bằng việc nghiêm khắc tuân thủ các bước nêu trên, mỗi chu trình sẽ đưa đến những kiến thức được thẩm định (validated learning). Tri thức được thẩm định nghĩa là chúng ta thử – ở mức chính xác cần thiết tối thiểu – những giả định chính của mô hình kinh doanh để đánh giá xem liệu chúng có thành công hay không và sau đó quyết định theo đuổi chúng, chuyển hướng, hoặc dừng lại.

Tiến trình Khởi nghiệp Tinh gọn tương đối ít tốn kém, trong môi trường doanh nghiệp chúng ta có thể theo đuổi đồng thời nhiều mô hình kinh doanh khả dĩ bằng việc sử dụng Nguyên tắc Quyền chọn (Principle of Optionality).

CHÚ Ý

Quyền chọn là gì?

Quyết định mua một quyền chọn cho chúng ta quyền chứ không phải là nghĩa vụ phải làm điều gì đó trong tương lai (điển hình như khi mua hoặc bán một tài sản với giá cố định). Các quyền chọn có giá và ngày hết hạn. Vé xem hòa nhạc, sự đồng ý đi ăn tối với ai đó và quyết định đầu tư cho sự phát triển một sản phẩm mới đều là những ví dụ về quyền chọn.

Hình 2-4. Chu trình xây dựng-đánh giá-học hỏi

Đầu tư một lượng thời gian và tiền bạc cố định để khảo sát các thông số kinh tế của một ý tưởng – có thể là một mô hình kinh doanh, một sản phẩm hay một sự cải thiện tiến trình – là ví dụ về việc sử dụng quyền chọn để quản lý sự bất trắc của quyết định tiếp tục đầu tư. Chúng ta hạn chế tối đa phí tổn đầu tư (“mặt tiêu cực”) cho bất kỳ ý tưởng cá nhân nào với hy vọng rằng một số lượng nhỏ các ý tưởng sẽ đem lại thành công lớn, và loại bỏ việc đầu tư cho những ý tưởng không thành công, như được thể hiện trong Hình 2-5. Bằng cách khám phá đồng thời nhiều cách tiếp cận khả thi, quyền chọn là một khái niệm rõ ràng giúp bạn đưa ra các quyết định về biện pháp giúp đạt được kết quả mong muốn.

Hình 2-5. Nguyên tắc quyền chọn theo cuốn Antifragile: Things That Gain From Disorder (Khả năng cải thiện nghịch cảnh: Hưởng lợi từ hỗn loạn) của Nassim Nicholas Taleb, 2012).

BÍ QUYẾT

Quá trình thực hiện

Giảm thiểu mặt tiêu cực và chắc chắn rằng mọi quyết định ít nhất đều tạo ra mặt tích cực nào đó (ngay cả khi chỉ là một thông tin mới) là một trong vài kỹ thuật mà các doanh nghiệp sử dụng trong các tình huống bất trắc, khi mà lập luận theo lô-gic đơn giản “nguyên nhân-kết quả” không phải là cách phù hợp để quản lý rủi ro. Trong cuốn Effectuation: Elements of Entrepreneurial Expertise (tạm dịch: Tư duy hướng tới hiệu quả: Những thành tố của kinh doanh tinh thông), Tiến sỹ Saras Sarasvathy, một nhà khoa học nữ đầy kinh nghiệm đã mô tả một khuôn khổ kinh doanh dựa trên nghiên cứu về cách mà các doanh nghiệp vận hành trong đời thực.

Giới hạn đầu tư ban đầu và tạo ra sự khan hiếm nguồn lực là việc quan trọng trong quản lý rủi ro từ sự đổi mới. Vì hiểu rằng nhiều ý tưởng đổi mới sẽ không thành công, chúng ta phải tìm được những thử nghiệm đơn giản và nhanh chóng để loại bỏ các ý tưởng kém cỏi một cách nhanh chóng và ít tốn kém nhất.

Bạn hãy nghiên cứu trường hợp bộ vi xử lý ARM, trung tâm của hầu hết các thiết bị di động ngày nay. Phiên bản đầu tiên của bộ vi xử lý này được Sophie Wilson và Steve Furber thiết kế tại Cambridge, Anh trong thập niên 1980. Thiết bị này đi từ một khái niệm thành một thiết kế đã sẵn sàng đưa vào sản xuất trong vòng 18 tháng. Khi được hỏi hai nhân viên trên đã thực hiện điều đó như thế nào, nhà lãnh đạo Herman Hauser trả lời: “Khi chúng tôi quyết định làm một bộ vi xử lý, sau này tôi mới hiểu, tôi nghĩ mình đã đưa ra hai quyết định lớn. Tôi tin tưởng nhóm làm việc đó và cho họ hai điều mà Intel và Motorola chưa bao giờ tạo điều kiện cho người của họ: Điều thứ nhất là không có tiền và điều thứ hai là không có người. Họ phải thiết kế nó thật đơn giản.”

Những khái niệm trung tâm của Khởi nghiệp Tinh gọn được thiết lập để nhanh chóng đánh giá các mô hình kinh doanh thông qua việc nhận diện và kiểm thử các giả thiết một cách khoa học. Vì vậy, chúng không chỉ được áp dụng trong việc tạo ra những doanh nghiệp mới. Ví dụ, những nguyên tắc hạn chế về thời gian và nguồn lực, theo đó việc hạn chế mặt tiêu cực và xây dựng một sản phẩm khả thi tối thiểu để kiểm thử giả thiết giá trị của bạn càng nhanh càng tốt với các khách hàng thực cần phải được áp dụng ngay từ bước khởi đầu của mọi nỗ lực. Chúng ta nên dùng cách tiếp cận này để khám phá tất cả những ý tưởng mới vốn có những điểm chưa được biết đến, những điểm không chắc chắn và vì vậy mang nhiều rủi ro – bất kể việc nó sẽ đem đến các sản phẩm mới, thay thế hệ thống hiện nay, thừa nhận những công cụ, tiến trình hoặc phương pháp mới, hoặc thực thi những giải pháp phần mềm thương mại có sẵn (commercial off-the-shelf software solutions- COTS). Bất cứ khi nào nghe nói về một dự án IT mới khởi nghiệp với một nguồn ngân sách lớn, những nhóm làm việc gồm hàng chục, hàng trăm người và một tiến trình nhiều tháng trời trước khi kết quả nào đó thực sự phải đạt được, bạn có thể biết rằng dự án đó sẽ tốn nhiều thời gian, tiền bạc và không đem lại giá trị mong muốn.

CẢNH BÁO

Áp dụng phương pháp Khởi nghiệp Tinh gọn vào các dự án IT nội bộ

Các nguyên tắc Khởi nghiệp Tinh gọn cũng rất quan trọng đối với các dự án kỹ thuật phần mềm nội bộ, bao gồm các dịch vụ và các cơ sở nền tảng như các đám mây riêng, những thay thế hệ thống. Những sáng kiến khổng lồ, với lộ trình hàng tháng hoặc thậm chí nhiều năm, không ngừng xuất hiện trong những loại dự án này, với những lời hứa đãi bôi về nỗ lực không ngừng để giải quyết một vấn đề khách hàng (nội bộ) thực sự. Trên thực tế, các nhóm xây dựng những hệ thống này thường coi thường nhu cầu và ưu tiên của khách hàng – chúng ta thường nghe thấy những lời giải thích kiểu như “chúng tôi biết những gì họ cần hơn chính họ”. Các dự án vận hành theo cách không thường xuyên đem lại giá trị gia tăng cho các khách hàng để nhận được phản hồi của họ, là một sự lãng phí lớn về thời gian và nguồn lực và hiếm khi đạt được mục đích, kết quả hoặc mục tiêu đặt ra. Ngoài ra, còn có những tác động tiêu cực và nghiêm trọng khác: Các hệ thống nội bộ trở nên khó sử dụng khiến công nhân tức giận, tác động đến tinh thần, năng lực và hiệu quả làm việc của họ. Ngoài những phí tổn do hoạt động kém hiệu quả, các doanh nghiệp này còn tạo ra những hệ thống góp phần làm phức tạp hơn môi trường sản xuất vốn đã vô cùng phức tạp. Kết quả tất yếu sẽ là một “hệ thống công nghệ ngoài luồng” (shadow IT), tức là các nhóm bỏ qua những dịch vụ do bộ phận IT chấp thuận hoặc duy trì để dùng những gì có thể giúp họ hoàn thành công việc của mình tốt hơn.

Các tổ chức có xu hướng bắt đầu các dự án mới với những nhóm lớn. Nguyên nhân thứ nhất là vì họ giả định (sai lầm) rằng điều này sẽ giúp hoàn thành công việc nhanh hơn. Thứ hai, họ sử dụng các tiến trình, ví dụ như chu kỳ ngân sách thường niên, vốn khuyến khích việc giành đất đai cho các dự án và nguồn lực được ưa thích. Tuy nhiên khi xây dựng các hệ thống phức tạp, những động lực này tất yếu sẽ dẫn tới việc gia tăng quy mô của hệ thống, tăng tính phức tạp và yêu cầu về quản lý sự phụ thuộc, trở nên thiếu hiệu quả và giảm chất lượng. Thiết lập và cố gắng duy trì giao tiếp hiệu quả trong các nhóm lớn tiêu tốn năng lực khổng lồ tại các dự án lớn. Trong khi đó, các hệ thống được tạo ra lại phát triển quá nhanh một cách lộn xộn và khó kiểm soát.

Trong môi trường này, vô cùng khó để thiết lập chu trình phản hồi hiệu quả nhằm xác định xem liệu những gì đang được xây dựng có giá trị hay không và có gắn với sản phẩm hay tầm nhìn của dự án không. Theo kinh nghiệm của chúng tôi, như được thể hiện trong Bảng 1-2, thì việc lập thêm các kế hoạch dự phòng cho tiến trình này còn có xu hướng khiến kết quả cuối cùng trở nên tồi tệ hơn thay vì tốt hơn.

Không nên đầu tư đầy đủ cho một phần công việc lớn nào trước khi có bằng chứng khẳng định sự đúng đắn của mô hình kinh tế và kinh doanh mà nó dựa vào. Khám phá đó phải do những nhóm nhỏ các nhân viên liên chức năng thực hiện trong khoảng thời gian giới hạn. Vấn đề này sẽ được trình bày trong Phần II.

KHI KHÁM PHÁ CÁC MÔ HÌNH KINH DOANH MỚI, HÃY GIẢM THIỂU KHOẢN ĐẦU TƯ VÀO PHÁT TRIỂN PHẦN MỀM

Một tổ chức bán lẻ lớn mà chúng tôi hợp tác muốn mở cửa hàng tại một thị trường mới – bước mở rộng đầu tiên của họ ra thị trường quốc tế. Nhóm IT được yêu cầu phải đưa hệ thống điểm bán hàng của họ thích ứng với hoạt động tại một quốc gia mới, tính toán một loại thuế doanh thu khác và sử dụng đồng tiền khác trong 8 tuần. Chúng tôi cho rằng thay đổi hệ thống hiện tại để làm việc với nhiều loại tiền tệ và cơ chế thuế khác nhau sẽ là một dự án IT kéo dài nhiều tháng và đòi hỏi sự đầu tư lớn. Bị buộc phải tìm kiếm những sự lựa chọn để xác nhận rằng giải pháp đó thực sự khả thi, nhóm này đã mã cứng (các lệnh chương trình được viết trực tiếp vào chương trình máy tính) loại thuế doanh thu mới này vào hệ thống máy chủ hiện có và thực hiện một lệnh đơn giản thay thế các biểu tượng tiền tệ trong thời gian thực cho các hệ thống trong cửa hàng mới. Mặc dù việc mở rộng ra quốc tế của doanh nghiệp này cuối cùng đã bị dừng lại do cuộc khủng hoảng tài chính năm 2008, nhưng phần mềm ban đầu của dự án đã khiến giải pháp đề xuất trở nên có hiệu lực với khoản đầu tư rất nhỏ, trước khi việc đầu tư vào một giải pháp mạnh, lâu dài và đầy đủ chức năng được thông qua.

Lưu ý cuối cùng là về hoạt động khám phá. Trong chương này, chúng tôi tập trung truyền tải tinh thần đổi mới khi áp dụng vào các sản phẩm, nhưng chính xác hơn thì những nguyên tắc tương tự cũng được áp dụng để giúp tổ chức thay đổi. Nhiều doanh nghiệp ra sức giới thiệu các phương cách, biện pháp, tiến trình và các công cụ mới trong toàn tổ chức nhưng lại bỏ qua thực tế rằng mọi người phản ứng với những đổi mới đó theo những cách khác nhau và không cách tiếp cận nào có thể được tất cả mọi người chấp nhận (tức là không có cách tiếp cận “một vừa cho tất cả” nào). Người ta thường thấy cách tiếp cận kiểu “vụ nổ lớn” (big bang) này không thể đạt được kết quả mong muốn hoặc sẽ lặng lẽ bị bỏ rơi để nhường đường cho một sáng kiến mới khác cố gắng giải quyết những thất bại của sáng kiến trước đó.

Chúng ta nên khám phá và kiểm thử những thay đổi tiến trình thực tế – được biết đến là các kaikaku2 trong triết lý về Tinh gọn – tương tự như khám phá các mô hình kinh doanh mới. Cụ thể là chúng ta nên để một bộ phận tương đối nhỏ và liên chức năng, bao gồm những người có xu hướng “cải cách” của tổ chức, kiểm thử chúng. Những người này phải yêu thích các thử nghiệm tiến trình được đề xuất và có những kỹ năng cần thiết để thực hiện chúng. Đối với một sự thay đổi được chứng tỏ là có giá trị, nhóm này có thể giúp các nhóm khác áp dụng nó để “vượt qua sự cách biệt” bên trong tổ chức cho đến khi nó trở thành phương pháp làm việc tiêu chuẩn. Tuy nhiên, cải cách tiến trình không dừng lại ở đây. Như chúng ta thảo luận trong Chương 6, tất cả các nhóm sẽ vẫn không ngừng tiến hành và phát triển những cải cách tiến trình, mang tên kaizen (cải tiến liên tục), như là một phần của công việc thường ngày nhằm hạn chế lãng phí đồng thời tăng số lượng và chất lượng. Văn hóa tổ chức sẽ được thảo luận chi tiết hơn tại Chương 11.

² Là một từ tiếng Nhật có nghĩa là phá vỡ triệt để cho vòng tròn cải thiện. Cách tiếp cận này là một hoạt động rất căng thẳng tiến hành trong nhà máy để tạo ra sự cải thiện hiệu năng ngay lập tức và để chứng minh rằng sự thay đổi có thể là tức thời. (BTV)

KHAI THÁC CÁC MÔ HÌNH KINH DOANH ĐÃ ĐƯỢC THẨM ĐỊNH

Các doanh nghiệp được tối ưu hóa để khai thác các mô hình kinh doanh, vốn “vượt qua sự cách biệt” – và chúng được thiết kế để làm vậy. Tuy nhiên, các công việc kỹ thuật thường rất dễ bị tắc nghẽn khi nâng cấp các sản phẩm hiện tại và giới thiệu các sản phẩm trong hạng mục sản phẩm đang được khai thác.

Các dự án hình thành nền tảng cho mô hình truyền thống để tiến hành các công việc của doanh nghiệp. Một dự án thường đòi hỏi một đề xuất kinh doanh phải được giải trình thì ngân sách mới được phân bổ, kéo theo một lượng nguồn lực lớn cho công tác kế hoạch, thiết kế và phân tích. Sau đó, nhiều bộ phận phải phối hợp công việc và thực thi kế hoạch. Thành công của một dự án được đo lường bằng việc hoàn thành kế hoạch ban đầu đúng thời gian và trong ngân sách cho phép. Tuy nhiên, điều đáng buồn là việc dự án đó có “thành công” không xét theo những tiêu chí này lại không liên quan đến việc chúng ta có thực sự tạo ra giá trị cho khách hàng và cho tổ chức của mình.

Các dữ liệu thu thập được từ việc phát triển các hệ thống trên nền tảng web cho thấy cách tiếp cận dựa trên kế hoạch để phát triển tính năng tạo ra rất ít giá trị cho khách hàng và tổ chức. Amazon và Microsoft (cùng với nhiều doanh nghiệp khởi nghiệp) sử dụng một kỹ thuật được gọi là kiểm thử A/B để thu thập thông tin về việc liệu một tính năng có thực sự đem lại giá trị cho người dùng hay không trước khi nó được đưa vào xây dựng hoàn thiện. Ronny Kohavi, người điều hành mảng Khai thác Dữ liệu và Cá nhân hóa của Amazon, trước khi gia nhập Microsoft trong vai trò Tổng Giám đốc mảng Thử nghiệm và Phân tích, đã tiết lộ một “số liệu thống kê khiêm tốn” rằng 60-90% các ý tưởng không cải thiện được những thông số mà chúng muốn cải thiện. Dựa trên các thử nghiệm của Microsoft, 1/3 các ý tưởng đã tạo ra sự thay đổi rất tích cực về mặt thống kê, 1/3 khác không tạo khác biệt đáng kể, 1/3 còn lại tạo ra thay đổi tiêu cực. Tất cả những ý tưởng đưa ra thử nghiệm đều được coi là những ý tưởng tốt, tuy nhiên, không có trực giác nào hay quan điểm chuyên gia nào có thể là thước đo tốt cho các giá trị mà ý tưởng của chúng ta muốn đem lại cho người dùng.

Cấu trúc dự án cũng là một yếu tố làm trầm trọng thêm vấn đề này. Các dự án thường mất nhiều thời gian từ khi bắt đầu đến khi kết thúc đến mức các bên liên quan đều cố gắng nhồi nhét càng nhiều tính năng càng tốt vào mỗi dự án, sợ rằng sẽ khó bổ sung tính năng một khi dự án đã hoàn thành. Hơn nữa, tiến trình lên kế hoạch diễn ra khi chúng ta mới chỉ có những thông tin ít ỏi và không hiểu hết về những rủi ro của dự án ngay từ khi bắt đầu. Do một loại định kiến trong nhận thức, được gọi là ngụy biện lập kế hoạch, mà các nhà điều hành có xu hướng “đưa ra quyết định dựa trên sự lạc quan phi thực tế chứ không phải dựa trên sự cân nhắc hợp lý những điểm được, mất và các khả năng. Họ đánh giá quá cao lợi ích và đánh giá quá thấp chi phí. Họ dệt nên các viễn cảnh thành công trong khi bỏ qua khả năng mắc sai lầm và tính toán không chính xác. Kết quả là họ theo đuổi những sáng kiến không đảm bảo là sẽ hoàn thành theo đúng ngân sách, đúng thời gian hoặc đem lại những kết quả mong muốn – hoặc thậm chí không chắc có hoàn thành hay không.”

Khi thực thi dự án, chúng ta phát hiện ra những thông tin mới – nhưng bởi vì không ai muốn các tính năng của họ bị cắt bỏ nên những thông tin mới thường dẫn đến tình trạng thêm việc, được gọi là “vượt phạm vi”³. Donald Reinertsen mô tả vòng xoáy tệ hại của việc vượt phạm vi khi chúng ta điều hành các dự án và phát hiện thêm các thông tin về “vòng xoắn ốc mẻ lớn”⁴, và khi kết hợp với ngụy biện lập kế hoạch, chúng khiến cho các dự án chi vượt ngân sách và quá hạn với mức độ tương ứng với quy mô của chúng. Đây là một lập luận quan trọng ủng hộ việc chia nhỏ các phần việc.

³ Vượt phạm vi (scope creep): Thuật ngữ trong quản lý dự án, chỉ những thay đổi, phát triển liên tục và không kiểm soát được về phạm vi dự án. Hiện tượng này thường xảy ra khi dự án không được định nghĩa, lập hồ sơ ghi chép hoặc kiểm soát rõ ràng. (BTV)

⁴ Vòng xoắn ốc mẻ lớn (large batch death spiral): Chỉ việc liên tục bổ sung tính năng vào dự án khi có thêm thông tin mới trong quá trình thực hiện, dẫn đến tình trạng thêm việc, gián đoạn, trì hoãn, v.v... (BTV)

Tất cả những đặc tính này và sự gia tăng quy mô dẫn đến việc các dự án khiến môi trường sản xuất trở nên phức tạp, điều mà – như chúng ta thảo luận trong Chương 14 – về căn bản không được dự trù như là một phần của tiến trình lập kế hoạch dự án. Sự phức tạp này dẫn đến chi phí gia tăng và vô số những công việc phát sinh trong các bộ phận thực hiện, làm gia tăng đáng kể chi phí và nỗ lực cần thiết để điều hành các dự án tương lai.

Cuối cùng, do cách tiếp cận của dự án là đánh giá con người theo tiêu chí hoàn thành công việc đúng thời gian và trong ngân sách dự kiến thay vì dựa vào giá trị đem lại cho khách hàng, nên hiệu quả sản xuất được tính bằng sản lượng (output) mà không phải bằng kết quả (outcomes). Điều này dẫn đến một số phản ứng không tốt. Các nhà thiết kế sản phẩm được đánh giá dựa trên khả năng xây dựng các văn bản chi tiết, toàn diện và mô tả đầy đủ các đề xuất giải pháp kinh doanh mà không xét đến việc liệu các sản phẩm và tính năng mà họ đạt được có đem lại giá trị cho người dùng hay không. Các lập trình viên được khen thưởng vì làm tròn công việc của mình thay vì đã tích hợp được công việc đó vào một hệ thống kiểm thử hoặc hoạt động có thể tồn tại khi đưa vào thế giới thực với quy mô hợp lý. Chúng ta tạo ra một “văn hóa anh hùng” thiếu bền vững, trong đó vinh danh việc làm quá sức và khả năng huy động cao (đảm bảo rằng mọi người đều bận bịu) chứ không phải là làm số lượng công việc ít nhất mà vẫn đạt được kết quả mong muốn.

Khả năng huy động cao đồng nghĩa với việc những công việc cần phối hợp sẽ mất nhiều thời gian hơn mới có thể hoàn thành vì những người bạn cần luôn bận rộn với các ưu tiên khác. Để đáp ứng những thời hạn nghiêm ngặt hơn, người ta không thể thực hiện việc duy trì hoặc cải thiện tiến trình (ví dụ như tự động hóa) để có thể tăng chất lượng và sản lượng. Điều này lại làm tăng chi phí cho việc làm thêm giờ, tăng áp lực lên tổ chức “phải làm việc chăm chỉ hơn” và gia tăng vòng xoáy tệ hại của tình trạng làm việc quá sức.

John Seddon, tác giả cuốn Freedom from Command & Control (tạm dịch: Tránh ra lệnh và kiểm soát), cho rằng “quan điểm bất hợp lý này rất phổ biến và mang tính hệ thống, không phải vì có ai đó xấu xa mà là vì yêu cầu đáp ứng hệ thống phân cấp xung đột với yêu cầu phục vụ khách hàng... Sự giỏi giang của mọi người được dùng để tồn tại chứ không phải để đổi mới sáng tạo.”

Làm thế nào chúng ta có thể tự thoát khỏi vòng xoáy ốc đi xuống này? Trong Phần III của cuốn sách, chúng tôi mô tả cách điều hành các chương trình làm việc quy mô lớn trong giai đoạn khai thác, sử dụng những nguyên tắc sau:

1. Xác định, đánh giá và quản lý kết quả chứ không phải là sản lượng. Áp dụng Yêu cầu Nhiệm vụ, chúng ta chỉ rõ “kim chỉ nam – các kết quả lý tưởng mà các bên mong muốn – cho chương trình làm việc của mình. Sau đó, ở cấp độ tổng quan, chúng ta lặp đi lặp lại, cụ thể hóa và đo lường kết quả mong muốn cho mỗi chu trình. Việc tìm ra cách để đạt được những kết quả này được giao cho các nhóm phụ trách chương trình. Dựa trên phản hồi từ các khách hàng thực sau mỗi vòng lặp, chúng ta tìm cách cải thiện chất lượng yêu cầu, tốc độ và chất lượng kết quả.

2. Quản lý công suất chứ không phải khả năng huy động. Chúng ta thực thi các nguyên tắc Kanban bằng cách làm rõ mọi công việc hữu hình và giới hạn công việc đang thực thi. Sau đó, chúng ta bắt tay ngay vào công việc và tìm cách hoàn thành nó càng sớm càng tốt. Chúng ta không ngừng cải thiện tiến trình để giảm thời gian của chu trình – thời gian thực hiện công việc – trong toàn hệ thống. Chúng ta sử dụng phân phối liên tục để phân công công việc thành những phần việc nhỏ với các vòng phản hồi dễ dàng hơn ở mức chi phí thấp.

3. Đảm bảo rằng mọi người được khen thưởng vì hướng đến một viễn cảnh cấp độ hệ thống dài hơi thay vì theo đuổi các mục tiêu chức năng ngắn hạn. Mọi người cần được khen thưởng vì sự phối hợp liên tục và hiệu quả (đôi bên cùng có lợi), vì giảm thiểu số lượng công việc cần thiết để đạt được kết quả mong muốn, và vì giảm được tính phức tạp của các hệ thống mà chúng ta tạo ra để thiết lập khả năng đạt được các kết quả đó.

Không nên bị phạt khi thất bại, thay vào đó, chúng ta phải xây dựng văn hóa trải nghiệm và phối hợp, thiết kế những hệ thống đảm bảo an toàn khi thất bại, và đưa các tiến trình vào thực hiện để qua đó có thể học hỏi từ các sai lầm và sử dụng những thông tin này nhằm khiến các hệ thống của chúng ta bền bỉ hơn.

CÂN BẰNG DANH MỤC ĐẦU TƯ CỦA DOANH NGHIỆP

Chìa khóa để quản lý hồ sơ kinh doanh của một doanh nghiệp, như với bất kỳ khoản đầu tư tài chính nào khác, là sử dụng một mô hình kinh tế. Tuy nhiên, đây không phải là phương pháp phổ biến. Trong cuộc khảo sát 161 doanh nhân toàn cầu như Hình 2-6, chỉ có 14% người được hỏi cho biết đã sử dụng một mô hình kinh tế để đưa ra các quyết định đầu tư sản phẩm và dịch vụ. Đáng ngạc nhiên là 13% thừa nhận rằng quan điểm của những người được trả lương cao nhất (còn gọi là phương pháp HiPPO – Highest Paid Person’s Opinion) là nhân tố quyết định chính. 47% cho biết chỉ sử dụng phương pháp ra quyết định ít khó khăn hơn một chút là thông qua ủy ban.

Quyết định thông qua ủy ban là cách ra quyết định phát triển dịch vụ phần mềm nhiều hãng

"Hãy chọn câu trả lời về cách mà công ty của bạn ra quyết định về việc sản phẩm nào sẽ được sử dụng."

Hình 2-6. Các doanh nghiệp đưa ra những quyết định đầu tư theo cách nào?

Trong cuốn Escape Velocity: Free Your Company’s Future from the Pull of the Past (tạm dịch: Tăng tốc: Giải phóng tương lai của công ty bạn khỏi sự níu kéo của quá khứ), Geoffrey Moore trình bày một “ma trận tăng trưởng/tính vật chất” để hình dung những quyết định đầu tư hiện thời, được thể hiện trong Hình 2-7, và mô tả cách phân biệt các công ty có chiến lược đầu tư hiệu quả và những công ty khác. Trục y của biểu đồ biểu thị liệu một doanh nghiệp cụ thể có quan trọng đối với bạn so với các doanh nghiệp khác hay không (“quan trọng” có nghĩa là tạo ra 5-10% hoặc nhiều hơn tổng thu nhập hoặc lợi nhuận). Trục x biểu thị tỷ lệ tăng trưởng của doanh nghiệp theo các giá trị tuyệt đối.

Hình 2-7. Ma trận tăng trưởng vật chất trong quản lý hồ sơ đầu tư (từ cuốn Escape Velocity: Free Your Company’s Future from the Pull of the Past của Geoffrey A. Moore, 2011)

Vào năm 2014, nhiều tổ chức như Microsoft, IBM và HP có vị thế dẫn đầu thị trường trong góc 3, tương ứng với giai đoạn C (một thị trường trưởng thành) trong Hình 2-3. Nhưng, như được thể hiện trong Hình 2-7, không hãng nào có thể phát triển (chứ không phải là thâu tóm) một thị phần lớn trong giai đoạn B (tương ứng với góc 2) bất chấp những khoản đầu tư lớn cho nghiên cứu và phát triển (R&D) vốn đã dẫn đến những thương vụ mới trong góc 1. Trái lại, trong thập kỷ qua, Amazon, Google và Apple đều đã xây dựng các thương vụ mới có tốc độ tăng trưởng nhanh chóng và trở thành một phần quan trọng của doanh nghiệp.

Để hiểu tại sao nhiều công ty không tạo ra được thương vụ trong góc 2, chúng ta phải hiểu động lực của hồ sơ đầu tư doanh nghiệp. Điều này được mô tả trong mô hình ba đường chân trời được trình bày bằng đồ thị trong Hình 2-8. Chân trời 1 bao gồm bộ sản phẩm và thương vụ cốt lõi của bạn (tương ứng với góc 3 trong Hình 2-7).

Hình 2-8. Ba đường chân trời (từ cuốn Escape Velocity: Free your Company’s Future from the Pull of the Past của Geoffrey A. Moore, 2011)

Những khoản đầu tư trong các thương vụ Đường chân trời 1 sẽ đem lại kết quả trong cùng một năm và cơ bản sẽ có biểu hiện của dạng phát triển các sản phẩm hiện có và xây dựng các sản phẩm mới thuộc dòng sản phẩm hiện tại. Đường chân trời 2 là tập hợp những thương vụ đang được hình thành tạo nên thương vụ cốt lõi của tương lai. Những điều này đòi hỏi phải có sự đầu tư đáng kể và sự quan tâm của bộ phận bán hàng và tiếp thị mới có thể thành công, nhưng sẽ không đem lại kết quả tương xứng với những khoản đầu tư của Đường chân trời 1.

Đường chân trời 3 là phạm vi của Khởi nghiệp Tinh gọn, khi mà chúng ta kiểm thử các mô hình kinh doanh mới và cố gắng tạo ra một sản phẩm phù hợp với thị trường cho các thương vụ mới. Chúng ta đặt mục tiêu đầu tư đủ thời gian và tiền bạc để tạo ra một runway (đường băng) nhằm phát hiện một sản phẩm phù hợp với thị trường trước khi quyết định đầu tư tiếp. Sau đó, chúng ta hoặc là chuyển ý tưởng vào Đường chân trời 2 hoặc là gác lại việc đó, có lẽ cho đến khi các điều kiện thị trường hoặc những tiến bộ về công nghệ thuận lợi cho việc kiểm thử trở lại.

Có ba vấn đề nghiêm trọng mà nếu hiệp lực lại có thể giết chết các thương vụ đưa nó vào Đường chân trời 2. Thứ nhất, chúng đòi hỏi phải có sự đầu tư đáng kể về nguồn lực nghiên cứu, bán hàng và tiếp thị mà không đem lại doanh thu tương xứng – theo các thông số mà các bộ phận thường tính toán. Thứ hai, mỗi một đường chân trời lại đòi hỏi các biện pháp quản lý và hỗ trợ khác nhau mới thành công, như được thể hiện trong Bảng 2-2. Áp dụng mù quáng một cách tiếp cận nhất quán cho các đường chân trời sẽ gây ra thất bại. Cuối cùng, như Clayton Christiensen thảo luận trong cuốn The Innovator’s Dilemma (Thế lưỡng nan của nhà cải cách⁵), các doanh nghiệp đang có lãi thường miễn cưỡng không muốn từ bỏ lợi nhuận và thị phần của mình bằng cách sản xuất các sản phẩm siêu đổi mới – những thứ có thể đe dọa giá trị cốt lõi và thị trường hiện tại của họ.

⁵ Đã được Alpha Books mua bản quyền và xuất bản năm 2012. (BTV)

Bảng 2-2. Ba đường chân trời

Chúng ta thường thấy những vấn đề này hợp lực lại để ngăn chặn, không cho các thương vụ qua được đường chân trời 2, ngay cả tại những doanh nghiệp đã làm rất tốt việc khám phá lẫn khai thác các mô hình kinh doanh. Cuối cùng, các công ty khác lại đưa chúng ra thị trường với những kết quả tuyệt vời. Công ty Xerox PARC đã sáng chế ra GUI (giao diện đồ họa người dùng) hiện đại (cũng như là nhiều thành phần khác của hệ thống máy tính hiện đại), nhưng “những cái đầu đựng mực”⁷ ở tổng hành dinh của Xerox “không hiểu gì về một chiếc máy tính hay công dụng của chiếc máy đó cả” và vì thế cuối cùng thì chính Apple và Microsoft mới là người đưa những chiếc máy tính đó vào từng phòng khách của mọi người.

⁷ Những cái đầu đựng mực(toner head): Biệt danh được các chuyên gia nghiên cứu ở Xerox dùng để gọi các nhà lãnh đạo của công ty, vốn thường là những người có tư duy marketing và không am hiểu sản phẩm. (BTV)

Hãng máy ảnh khổng lồ Kodak, công ty nộp đơn phá sản năm 2012, mới chính là công ty phát minh ra máy ảnh kỹ thuật số. Steve Sasson và nhóm của ông thuộc Phòng Nghiên cứu Thiết bị Kodak đã có bước cải tiến đột phá vào năm 1975. Tuy nhiên, các nhà quản lý của nhóm này lại bối rối, không hiểu tại sao khách hàng lại muốn xem ảnh trên màn hình. Doanh nghiệp của họ được tối ưu hóa để phát triển các bức ảnh – sản xuất giấy ảnh, film và các thiết bị phụ trợ khác – chứ không phải để ghi lại những khoảnh khắc hay kỷ niệm.

CẢNH BÁO

Tại sao không thể thuê hay mua phương pháp cải cách

Một số doanh nghiệp đã thâu tóm các doanh nghiệp khởi nghiệp trong nỗ lực nhằm tiếp cận xu hướng hiện tại và thúc đẩy cải cách – có lẽ là để đa dạng hóa và cân bằng hồ sơ đầu tư của mình, để biến mình thành “các phòng thử nghiệm đổi mới” hoặc để đánh dấu một ô trong giai đoạn A, góc 1 hoặc đường chân trời 3. Chúng ta đã chứng kiến rất rõ kết quả tệ hại của cách thức này. Nó không tạo ra kết quả mong muốn và các nhân viên cao cấp rời công ty ngay khi họ có thể thực hiện những lựa chọn của mình. Những vấn đề này xảy ra khi công ty được mua – đang nghiên cứu một sản phẩm ở đường chân trời 3 hoặc 2 – lại phải chịu sự quản lý, các mục tiêu tài chính và các cấu trúc quản lý đang ở đường chân trời 1 của doanh nghiệp mua, dẫn đến sự hủy hoại hoàn toàn khả năng đổi mới của công ty. Đôi khi người của tổ chức mẹ được luân phiên qua bộ phận cải cách với hy vọng rằng sẽ có phép màu nào đó giúp họ học được phương pháp đổi mới trong một đường chân trời khác mà không khiến họ bị sốc văn hóa. Việc mua hay thuê các phương pháp cải cách thường thất bại vì cùng một lý do: Việc đưa những con người vĩ đại vào một môi trường văn hóa quan liêu hoặc lệch lạc không giúp thay đổi môi trường đó mà chỉ phá hoại họ. Giải pháp là phải nỗ lực chuyển đổi văn hóa của tổ chức, gây dựng cách lãnh đạo và quản lý hiệu quả, phù hợp với mỗi đường chân trời. Điều này vô tình cũng sẽ làm mất đi nhu cầu thuê mướn hoặc mua các đội ngũ cải cách.

Giả thiết của chúng tôi là các tổ chức tồn tại và phát triển trong trung và dài hạn bằng cách cân bằng khả năng tiếp tục khám phá những mô hình kinh doanh tiềm năng mới với việc khai thác hiệu quả các mô hình hiện có. Trên thực tế, một trong những dấu hiệu của một tổ chức thích nghi và kiên cường thực sự là tổ chức đó không ngừng phá bỏ các mô hình kinh doanh hiện tại để tìm kiếm những cơ hội trong tương lai cũng như những thị trường và khách hàng mới.

Ví dụ, việc Amazon theo đuổi mảng sách điện tử và sản xuất thiết bị Kindle đã phá vỡ mô hình kinh doanh chính của công ty khi đó là bán sách thông thường. Sự phát triển của Amazon Marketplace đã giúp các nhà buôn khác tác động đến hạ tầng cơ sở của Amazon và tiềm ẩn khả năng giảm doanh số bán hàng của công ty. Hãng 3M xác định chiến lược của mình là không ngừng đổi mới sản phẩm và đặt mục tiêu doanh thu từ các sản phẩm được giới thiệu trong 5 năm là 30% và đã vượt mục tiêu này năm 2008. Inge G. Thulin, Chủ tịch kiêm Giám đốc Điều hành của hãng 3M, hy vọng rằng con số này sẽ đạt 40% vào năm 2017.

Intuit sử dụng một mô hình đơn giản để cân bằng đường chân trời 1, 2 và 3, như được thể hiện trong Bảng 2-3. Google đi theo mô hình tương tự, nhưng tỷ lệ phân bổ khác: 70% cho Đường chân trời 1, 20% cho Đường chân trời 2 và 10% cho đường chân trời 3.

Bảng 2-3. Đường chân trời và thông số cải cách của Intuit

Điểm quan trọng nhất luôn phải nhớ khi cân bằng các đường chân trời là nếu ban lãnh đạo cao cấp không đóng vai trò tích cực trong quản lý đầu tư, bao gồm việc áp dụng các biện pháp quản lý phù hợp đối với các đường chân trời khác nhau và quan tâm khích lệ các biện pháp này thì các doanh nghiệp cốt lõi sẽ luôn tìm ra cách sử dụng ảnh hưởng tập thể của mình để gạt ra ngoài lề và cuối cùng là vô hiệu hóa các đường chân trời khác. Nếu các rào cản về văn hóa và quản lý đơn giản là quá mạnh cho kiểu tiếp cận “hai mặt” này thì giải pháp thay thế là thành lập một đơn vị kinh doanh độc lập nhất có thể.

AETNA ĐÃ TẠO RA CÁC CÔNG TY MỚI ĐỂ PHÁ BỎ CÁC THƯƠNG VỤ CỐT LÕI CỦA MÌNH NHƯ THẾ NÀO?

Aetna, giống như tất cả các tổ chức tham gia thị trường y tế của Mỹ, biết rằng Đạo luật Chăm sóc Sức khỏe Hợp túi tiền của chính quyền Obama đem đến những rủi ro nghiêm trọng và đồng thời cũng là một cơ hội lớn. Với 160 năm hoạt động vào thời điểm dự thảo được ký thành luật, Aetna quyết định thành lập một công ty mới tên là Healthagen, “một tổ chức riêng rẽ, được đầu tư riêng, trả thù lao riêng và quản lý riêng, vì vậy họ không chịu ảnh hưởng của tiến trình quản lý tương tự tại Aetna” với mục đích tạo đột phá trong thị trường cung cấp chăm sóc y tế bằng công nghệ và những mô hình kinh doanh mới. Ban đầu Healthagen có mục tiêu đạt 1,5-2 tỷ doanh thu mỗi năm.

Aetna cũng thành lập một công ty con khác theo cách tương tự để hình thành một thị trường tiêu dùng và thực hiện các mô hình trao đổi riêng. Mark Bertolini, Chủ tịch Hội đồng Quản trị kiêm Giám đốc Điều hành của Aetna cho biết rằng mục đích của ông là xây dựng một hệ sinh thái cạnh tranh dựa trên công nghệ, điều sẽ phá vỡ hoạt động cốt lõi của chính Aetna.

KẾT LUẬN

Mọi ý tưởng đều có vòng đời riêng, trong đó những ý tưởng thành công tạo ra lợi thế cạnh tranh cho những bên tiếp nhận sớm và cuối cùng trở thành nền tảng cho những cải cách cấp cao hơn. Các doanh nghiệp phải đảm bảo rằng họ có kênh cung cấp các ý tưởng mới nhằm tạo cơ sở tăng trưởng trong tương lai. Việc quản lý hồ sơ đầu tư doanh nghiệp hiệu quả đòi hỏi chúng ta phải hình thành và áp dụng một mô hình kinh tế nhằm cân bằng các khoản đầu tư trên cả ba đường chân trời. Để tìm hiểu thêm về quản lý hồ sơ đầu tư, chúng tôi khuyến nghị các bạn đọc cuốn Escape Velocity: Free Your Company’s Future from the Pull of the Past của Geoffrey Moore.

Chúng tôi hy vọng rằng sẽ có một vài ý tưởng cho các thương vụ mới được thai nghén trong đường chân trời 3. Bởi vì không thể dự đoán ý tưởng nào sẽ thành công nên chúng ta áp dụng Nguyên tắc Quyền chọn và giả định rằng nhiều ý tưởng sẽ thất bại nhưng một số ý tưởng sẽ thành công. Chúng ta áp dụng phương pháp Khởi nghiệp Tinh gọn để chuyển hướng các mô hình kinh doanh cho những thương vụ này cho đến khi các nhóm hết nguồn lực hoặc phát hiện một sản phẩm phù hợp với thị trường và giành được động lực để tiếp tục thúc đẩy. Nhiều ý tưởng sẽ không bao giờ tiến được vào đường chân trời 2, nhưng những ý tưởng vào được sẽ cần có cách quản lý khác biệt về căn bản. Trong đường chân trời 3, chúng ta chỉ quan tâm đến việc tìm một sản phẩm phù hợp với thị trường, nhưng trong đường chân trời 2 chúng ta cần định dạng và quản lý một loạt rủi ro cụ thể và lớn hơn đối với doanh nghiệp của mình. Thay vì cải cách mô hình kinh doanh, chúng ta chuyển sang đổi mới tăng dần, tức là chúng ta sẽ cần một loạt các kỹ năng khác.

Có quá nhiều doanh nghiệp đã đánh sập sự đổi mới khi cố gắng quản lý những khoản đầu tư ở đường chân trời 2 và 3 bằng các chiến lược của đường chân trời 1. Trong phần còn lại của cuốn sách này, chúng tôi sẽ bỏ qua đường chân trời 1 (mặc dù nhiều nguyên tắc và kỹ thuật được mô tả trong Phần III có thể được áp dụng một cách hữu ích trong giai đoạn này). Phần II của cuốn sách xem xét giai đoạn khám phá mà chúng ta sẽ thúc đẩy trong các khoản đầu tư tại đường chân trời 3. Phần III thảo luận cách phát triển quy mô nhanh chóng trong giai đoạn khai thác, cũng bằng cách sử dụng các nguyên tắc tinh gọn đã được áp dụng vào sản xuất trong nhiều thập kỷ để không ngừng gia tăng chất lượng và giảm chi phí. Trong Phần IV, chúng tôi thảo luận cách chuyển đổi doanh nghiệp, bắt đầu bằng việc phát triển một môi trường văn hóa cải cách.

Câu hỏi dành cho độc giả:

◆ Tổ chức của bạn sử dụng khuôn khổ nào để cân bằng hồ sơ đầu tư vào các lĩnh vực khám phá các mô hình kinh doanh mới, khai thác các mô hình đã được khẳng định giá trị và phát triển các hoạt động cốt lõi?

◆ Bạn có thể nhanh chóng nắm được danh mục đầu tư này ở đâu?

◆ Thông số hiệu năng nào được sử dụng để đánh giá hiệu quả của các hoạt động trong từng lĩnh vực này?

◆ Tỷ lệ đầu tư vào đường chân trời 1, 2 và 3 trong tổ chức của bạn là gì? Điều đó là có tính toán hay chỉ là tình cờ? Bạn nghĩ nó nên là bao nhiêu?

◆ Làm thế nào để ban lãnh đạo cao cấp ủng hộ các khoản đầu tư vào đường chân trời 2 và 3, và rằng sự chuyển tiếp giữa các đường chân trời được quản lý theo cách tối đa hóa các thông số hiệu năng tương ứng cho từng khoản đầu tư.

Phần IIKHÁM PHÁ

Người tốt hoang mang khi kẻ xấu lộng hành.

− W. B. YEATS

Khi đối mặt với một cơ hội hay một vấn đề mới phải giải quyết, bản năng của chúng ta là đi thẳng đến giải pháp mà không khám phá thật xác đáng phạm vi của vấn đề, xem xét các giả định gắn với giải pháp được đề xuất hoặc nỗ lực tự khẳng định tính hiệu quả của giải pháp đó với những người dùng thực.

Có thể thấy bản năng này tồn tại khi chúng ta thiết kế các sản phẩm mới, bổ sung những tính năng mới vào các sản phẩm hiện tại, giải quyết các vấn đề về tiến trình và công tác tổ chức, bắt đầu các dự án hoặc thay thế các hệ thống hiện tại. Đó chính là điều thúc đẩy chúng ta tìm cách mua các công cụ đắt tiền để giải quyết tất cả các trường hợp, cố gắng tìm một phương pháp mới hoặc luồng không khí mới cho công tác tổ chức của toàn công ty, hoặc đầu tư vào các chương trình “đánh cược sinh mệnh của công ty”.

Tồi tệ hơn, chúng ta thường đắm chìm với các giải pháp của mình, sau đó thì vướng vào tình trạng “Ngụy biện chi phí chìm¹” khi cố tình bỏ qua những bằng chứng khiến chúng ta phải suy nghĩ liệu có nên tiếp tục theo đuổi những giải pháp đó không. Khi bạn đang ở một vị trí quyền lực thì các sai lầm này có thể gây hậu quả khủng khiếp. Một đồng nghiệp của chúng tôi suýt nữa bị một khách hàng ngừng hợp tác vì đã liều lĩnh đặt câu hỏi về đề xuất kinh doanh của một dự án cụ thể.

¹ Sunk cost fallacy: Tình trạng bạn tiếp tục làm một việc gì đó vì đã đầu tư quá nhiều thời gian, tiền bạc và công sức vào đó, tuy nhiên việc làm này không phải là lựa chọn khôn ngoan nhất. (ND)

Nếu chúng ta có sức mạnh siêu nhiên, nó sẽ xuất hiện một cách kỳ diệu bất cứ khi nào một vấn đề hoặc một cơ hội mới được đưa ra thảo luận. Sứ mệnh của chúng ta sẽ là ngăn cản bất kỳ ai khởi động một chương trình lớn để giải quyết một vấn đề hoặc theo đuổi một cơ hội cho đến khi họ hoàn thành những việc sau:

• Xác định kết quả kinh doanh cụ thể cần đạt được.

• Xây dựng nguyên mẫu khả thi nhỏ nhất có khả năng biểu thị sự tiến bộ có thể đo lường được hướng đến kết quả đó.

• Chứng minh rằng giải pháp đưa ra thực sự đem đến giá trị cho những khách hàng mà nó nhắm đến.

Bởi vì chúng ta chỉ là những con người bình thường, chúng tôi tin rằng các bạn sẽ giữ cuốn sách này để sử dụng khi phù hợp.

Trong phần này, chúng tôi thảo luận cách khai thác các cơ hội và các phạm vi của vấn đề (Problem Space²) bằng một cách tiếp cận khoa học và hệ thống để giải quyết vấn đề. Với cách tiếp cận kiểm thử, chúng ta có thể quản lý hiệu quả các rủi ro và tạo điều kiện cho các nhóm đưa ra những quyết định và nhận định tốt hơn trong điều kiện bất trắc vốn luôn là đặc điểm của tiến trình cải cách.

² Có nghĩa là toàn bộ phạm vi các thành tố tồn tại trong tiến trình tìm giải pháp cho một vấn đề, bắt đầu với việc “nhận diện vấn đề”, sau đó tiến đến “xác định và kiểm thử các giải pháp khả thi” và kết thúc bằng việc “lực chọn và thực thi một giải pháp”. (ND)

Chương 3Định hình và đánh giá rủi ro đầu tư

Nghi ngờ không phải một trạng thái dễ chịu, nhưng tin chắc thì thật ngu xuẩn.

− VOLTAIRE

Đối với các doanh nghiệp đang kiểm thử các mô hình kinh doanh và sản phẩm mới, ví dụ như các doanh nghiệp khởi nghiệp, thì rủi ro lớn nhất là thất bại trong việc tạo ra thứ đem đến giá trị cho người dùng. Khung Doanh nghiệp Tinh gọn cho phép chúng ta nhanh chóng loại bỏ những ý tưởng không đem lại giá trị hoặc sẽ không được chấp nhận trong thời gian cần thiết để không lãng phí các nguồn lực.

Tuy nhiên, các nguyên tắc của Khởi nghiệp Tinh gọn cũng có thể được áp dụng cho tất cả các loại hoạt động bên trong các doanh nghiệp bao gồm thiết kế các công cụ nội bộ, cải thiện tiến trình, thay đổi tổ chức, thay thế hệ thống và các chương trình GRC (Governance, Risk and Compliance – Quản lý, Rủi ro và Tuân thủ).

Trong chương này chúng tôi trình bày các nguyên tắc và khái niệm có thể giúp hình thành cách tiếp cận hệ thống của việc quản lý rủi ro từ các công việc trong kế hoạch bằng cách thu thập thông tin nhằm làm giảm tính bất trắc. Khuôn khổ này hình thành nền tảng cơ bản cho cách tiếp cận thực tế đối với việc khai thác các cơ hội mới mà chúng tôi trình bày trong toàn bộ nội dung còn lại trong Phần II.

ĐỊNH HÌNH RỦI RO ĐẦU TƯ

Về cơ bản, chúng ta phải xây dựng được một đề xuất kinh doanh với một kế hoạch hỗ trợ đề xuất này trước khi có thể triển khai nó trong các doanh nghiệp. Việc này đòi hỏi một đội xây dựng tài liệu chi tiết đánh giá các giá trị mà sáng kiến này sẽ đem lại. Đề xuất kinh doanh này mô tả các nguồn lực cần thiết, những sự hỗ trợ khác và cuối cùng là một tập hợp chi tiết các con số thể hiện công việc cụ thể trong kế hoạch với dự kiến các chi phí, thông số chính, một kế hoạch nguồn lực và các khung thời gian. Tùy thuộc vào mức độ các chi tiết và dự kiến mức đầu tư cần thiết, tiến trình này có thể mất vài tuần hoặc vài tháng mới có thể hoàn thành.

Một mục đích quan trọng của tiến trình lập kế hoạch là để hỗ trợ một quyết định đầu tư. Để đưa ra quyết định này, chúng ta phải hiểu rõ về những rủi ro liên quan đến khoản đầu tư đó. Theo Douglas Hubbard, chúng ta xác định rủi ro là “một trạng thái bất trắc khi có thể có một vài trong số các khả năng liên quan đến thua lỗ, tai ương hoặc các kết quả không mong đợi khác,” và đánh giá rủi ro là “một tập hợp những khả năng, mỗi khả năng có xác suất thành công và xác suất thua lỗ xác định.” Ví dụ: “Chúng tôi tin rằng có 50% cơ hội dự án sẽ bị dừng lại với tổn thất 2 triệu đô-la trong quá trình phát triển.”

Trong cuốn How to measure anything (tạm dịch: Cách đo lường mọi việc), Hubbard thảo luận về công việc của mình khi phân tích các thương vụ đầu tư IT như sau:

Mỗi đề xuất kinh doanh này có từ 40 đến 80 biến số bao gồm chi phí phát triển ban đầu, tỷ lệ chấp nhận, cải thiện năng suất, tăng trưởng doanh thu... Trong mỗi giải pháp, tôi nhập một lệnh (macro) trong Excel để tính toán giá trị thông tin cho mỗi biến số. Tôi sử dụng giá trị này để xác định cần tập trung các nỗ lực đánh giá vào đâu. Khi tôi nhập một lệnh để tính toán giá trị thông tin cho mỗi biến số này, tôi bắt đầu nhận ra một số quy luật sau: 1) Phần lớn các biến số đều có giá trị thông tin bằng 0; 2) Các biến số có giá trị thông tin cao thường là những gì mà khách hàng chưa bao giờ đánh giá; 3) Những biến số mà các khách hàng thường sử dụng nhiều thời gian để đo lường lại thường có giá trị thông tin rất thấp.

Lấy việc đánh giá các chi phí phát triển để kết hợp các đề xuất kinh doanh nhằm giúp dự án được phê chuẩn làm ví dụ. Điều này thường liên quan đến việc phân tích khối lượng công việc kéo dài nhiều tháng trong tương lai, chia thành các phần việc nhỏ và đánh giá nỗ lực cần thiết cho mỗi phần việc đó. Tuy nhiên, như Hubbard lưu ý: “Ngay cả trong các dự án có chi phí phát triển rất không chắc chắn, chúng ta cũng không thấy rằng những chi phí đó có giá trị thông tin đáng kể đối với quyết định đầu tư. Ẩn số quan trọng nhất là liệu dự án có bị đình chỉ không. Biến số quan trọng tiếp theo là khả năng huy động hệ thống, trong đó có khả năng triển khai nhanh chóng của hệ thống và việc liệu có người biết tận dụng nó hay không.”

Như vậy về bản chất, đề xuất kinh doanh đó trở thành một cuốn tiểu thuyết khoa học viễn tưởng dựa trên một bối cảnh mà người ta hiểu biết rất ít, hoặc thậm chí là không hề tồn tại! Trong khi đó, phần lớn thời gian lại bị lãng phí vào việc lập kế hoạch chi tiết, phân tích và đánh giá với lượng thông tin lớn nhưng có giá trị vô cùng hạn chế. Theo một nghiên cứu của Donald Reinertsen, tác giả cuốn The

Principles of Product Development Flow: Second Generation Lean Product Development (tạm dịch: Các nguyên tắc của dòng phát triển sản phẩm: Sự phát triển sản phẩm tinh gọn thế hệ thứ hai), có đến 50% tổng thời gian phát triển sản phẩm được sử dụng cho những hoạt động tiền dự án¹ như vậy. Dĩ nhiên, điều đó dẫn đến những quyết định đầu tư tồi, kéo dài một cách không cần thiết các chu trình phát triển sản phẩm và tạo ra nhiều hậu quả tiêu cực khác:

¹ Hoạt động tiền dự án (fuzzy front end) hay còn gọi là Giai đoạn 0: Là thời điểm khởi đầu, thường dùng để xác định cơ hội, phát triển khái niệm trước khi bước vào quá trình phát triển sản phẩm chính thức. (BTV)

Chu trình phát triển sản phẩm kéo dài sẽ nhanh chóng làm giảm khả năng thu hồi vốn mà chúng ta hy vọng có thể đạt được từ các sản phẩm mới thành công.

◆ Điều nguy hiểm nhất là nhiều chu trình phát triển kéo dài sẽ trì hoãn thời gian nhận phản hồi của khách hàng để có thể khẳng định rằng sản phẩm mà chúng ta đang xây dựng có giá trị.

◆ Các hoạt động nghiên cứu thị trường cơ bản không thể dự báo chắc chắn về sự phù hợp của một sản phẩm đối với thị trường, đặc biệt là đối với các loại sản phẩm mới. Ví dụ, các nghiên cứu từng chỉ ra rằng xe tải nhỏ và iPods sẽ không thành công.

◆ Khi không có các dữ liệu tốt, mọi người có xu hướng tìm nguồn đầu tư cho các dự án yêu thích của mình. Đặc biệt, trong các doanh nghiệp IT, chúng ta thường thấy một lượng vốn lớn được rót vào các dự án thay thế hệ thống – ngay cả (có lẽ là đặc biệt là?) trong các tổ chức hoạt động trong các lĩnh vực có sự kiểm soát cao độ.

Có hai nhân tố mà chúng ta quan tâm trong một đề xuất kinh doanh. Thứ nhất là tính nhạy cảm của thông số chính đối với nhiều biến số khác nhau trong đề xuất kinh doanh. Thứ hai là mức độ bất trắc của những biến số có tác động lớn tới thông số chính. Xem xét sự phân bổ và phạm vi của các biến số then chốt, một cách tiếp cận đơn giản nhưng hiệu quả là thực hiện phương pháp mô phỏng Monte Carlo² để tìm ra những kết quả khả dĩ. Điều này sẽ cho phép chúng ta phát hiện những biến số cần được quan tâm để có thể đưa ra các quyết định đầu tư đúng đắn.

² Monte Carlo Simulation là một kỹ thuật phân tích rủi ro định lượng để xác định mức độ rủi ro hoàn thành dự án, được xem là một trong những kỹ thuật hay công cụ quan trọng nhất của quản trị rủi ro. (ND)

Để thực hiện mô phỏng Monte Carlo, chúng ta sử dụng một chiếc máy tính để tạo ra hàng nghìn kịch bản được sắp xếp ngẫu nhiên dựa trên mô hình phân bổ và các loại các biến số đầu vào, sau đó tính toán giá trị của thông số mà chúng ta quan tâm trong mỗi kịch bản. Đầu ra của thuật mô phỏng Monte Carlo là một biểu đồ tần số với số lượng các kịch bản trong mỗi phạm vi trên trục y và các loại biến số trên trục x. Các bạn có thể thực hiện một mô phỏng Monte Carlo bằng cách dùng Excel hoặc các công cụ khách hàng hiện có. Đầu ra của một kỹ thuật mô phỏng Monte Carlo cho một đề xuất kinh doanh có thể giống như Hình 3-1. Như Hubbard lưu ý, sự bất trắc trong ROI (tỷ suất hoàn vốn) cho các chương trình IT có xu hướng rất cao và gia tăng cùng với sự kéo dài của chương trình.

Hình 3-1. Đầu ra của kỹ thuật mô phỏng Monte Carlo

Vì bạn có thể thẩm định bằng cách thực hiện kỹ thuật mô phỏng Monte Carlo đối với các đề xuất kinh doanh của chính mình, nên ROI trong các chương trình IT không quá nhạy cảm đối với chi phí, nhưng đúng hơn là đối với việc liệu chương trình có bị đình chỉ hay không và khả năng huy động của hệ thống gốc là như thế nào. Những biến số này phụ thuộc chủ yếu vào việc liệu chúng ta có xây dựng sản phẩm đúng hay không. Tuy nhiên, tiến trình xây dựng kế hoạch doanh nghiệp tiêu chuẩn lại hầu như không đem lại giá trị cho việc này.

Chúng ta hãy làm rõ điều này. Trong nhiều doanh nghiệp, khoảng 30-50% tổng thời gian tiếp thị được sử dụng vào những hoạt động vốn không đem lại giá trị xét về khía cạnh giảm thiểu rủi ro của các khoản đầu tư. Các hoạt động giá trị-gần-bằng-0 này chủ yếu được thực hiện trong tiến trình xây dựng kế hoạch và quản lý tài chính. Theo kinh nghiệm của chúng tôi, hoạt động tiền dự án thể hiện cơ hội lớn nhất cho việc cải thiện tiến trình cơ bản kaikaku trong doanh nghiệp. Chúng ta có thể giảm mạnh lượng thời gian cần thiết và đưa ra quyết định đúng hơn bằng cách thực hiện cách tiếp cận hệ thống trong quản lý rủi ro.

Trong chương này, chúng ta thảo luận cách xử lý hoạt động tiền dự án cho các thương vụ và sản phẩm mới. Trong Chương 7, chúng tôi sẽ chỉ ra biện pháp thay đổi cách quản lý các công việc tồn đọng đặc trưng ở cấp độ tổng quan.

ÁP DỤNG PHƯƠNG PHÁP KHOA HỌC ĐỂ PHÁT TRIỂN SẢN PHẨM

Cách mà người khác giúp bạn hiểu những gì bạn đang làm có giá trị hay không là họ có gửi tiền cho bạn hay không.

− DONALD REINERTSEN

Khi có một lượng lớn những bất trắc về các thông số chính mà chúng ta quan tâm, chúng ta bắt đầu bằng việc nhận dạng các biến số có giá trị thông tin cao nhất, tức là những giả định rủi ro nhất. Đây là những gì thông số kết quả của chúng ta trở nên nhạy cảm nhất. Trong trường hợp cải cách mô hình kinh doanh và phát triển sản phẩm, Donald Reinertsen bình luận rằng “doanh thu thường xuyên là nơi chôn các xác chết”.

Cách thiếu hiệu quả nhất để thử nghiệm một mô hình kinh doanh hoặc ý tưởng sản phẩm là lên kế hoạch và xây dựng một sản phẩm hoàn chỉnh để xem liệu thị trường dự kiến có thực sự tồn tại hay không. Tuy nhiên, đây chính xác là những gì mà chúng ta vẫn làm mỗi khi đề xuất kinh doanh được phê chuẩn. Một phần của vấn đề là ngôn ngữ mà chúng ta sử dụng để mô tả tiến trình phát triển sản phẩm. Ví dụ, hãy xem xét thuật ngữ “các yêu cầu”. Chúng là các yêu cầu của ai? Có phải là của người dùng không? Trong cuốn Lean IT (tạm dịch: IT tinh gọn), Steve Bell và Mike Orzen bình luận rằng: “Người dùng thường không thể nói rõ và chính xác những gì họ cần, nhưng lại nhất quán về những gì họ không muốn... một khi họ thấy nó.”

Chúng ta nên ngừng sử dụng từ “các yêu cầu” trong phát triển sản phẩm, ít nhất là đối với những tính năng lớn. Thay vào đó, là các giả thiết. Chúng ta tin tưởng rằng một mô hình kinh doanh, hay một sản phẩm, hay một tính năng cụ thể, sẽ có giá trị đối với khách hàng. Nhưng chúng ta phải kiểm thử các giả định của mình. Chúng ta có thể thực hiện cách tiếp cận khoa học để kiểm thử các giả định này bằng cách tiến hành các thử nghiệm.

Trong trường hợp cải cách sản phẩm và mô hình kinh doanh, phương pháp Khởi nghiệp Tinh gọn cung cấp cho chúng ta một khuôn khổ hoạt động trong các điều kiện vô cùng bất trắc. Trong cuốn Running Lean (Vận hành tinh gọn³), Ash Maurya giải thích cách thực thi mô hình Khởi nghiệp Tinh gọn như sau:

3 Được Alpha Books mua bản quyền và xuất bản năm 2018. (BTV)

◆ Không dành nhiều thời gian vào việc tạo ra một mô hình kinh doanh phức tạp. Thay vào đó, thiết kế một Khung Mô hình Kinh doanh (Business model canvas – BMC⁴) đơn giản hóa, trong đó nắm bắt và truyền tải những giả định hoạt động then chốt của mô hình kinh doanh dự kiến.

⁴ Được phát triển bởi chuyên gia quản lý người Thuỵ Điển Alexander Osterwalder, thể hiện thông tin về các nhân tố đầu vào tạo nên chuỗi giá trị của một doanh nghiệp dưới dạng hình ảnh, được sử dụng rộng rộng rãi trong quá trình xây dựng, hoạch định một doanh nghiệp mới hoặc để phân tích tình hình kinh doanh hiện tại của công ty với 9 trụ cột gồm: Đối tác chính, Hoạt động kinh doanh chính, Nguồn lực chính, Giá trị thặng dư, Quan hệ khách hàng, Kênh thông tin và Phân phối, Phân khúc khách hàng, Cơ cấu chi phí và Dòng doanh thu. Khái niệm này được trình bày chi tiết trong cuốn Tạo lập Mô hình Kinh doanh do Alpha Books mua bản quyền và xuất bản năm 2016. (ND)

◆ Thu thập thông tin để nhận định liệu bạn có vấn đề nào đáng phải giải quyết không, có nghĩa là nó có thể giải quyết được và mọi người sẽ trả tiền cho nó nếu được giải quyết. Nếu có cả hai điều kiện này, chúng ta đã có được một sản phẩm phù hợp với thị trường.

◆ Sau đó thiết kế một sản phẩm khả thi tối thiểu (Minimum Viable Product – MVP) – một thử nghiệm được thiết kế để tối đa hóa việc thu thập thông tin phản hồi từ những người tiếp nhận sản phẩm đầu tiên với nỗ lực tối thiểu. Trong trường hợp chắc chắn rằng các kết quả MVP cho thấy giả định sản phẩm của bạn không có căn cứ, hãy chuyển hướng và bắt đầu lại. Tiếp tục tiến trình này cho đến khi bạn quyết định từ bỏ vấn đề ban đầu, cạn kiệt nguồn lực hoặc đã phát hiện ra một sản phẩm phù hợp với thị trường. Trong trường hợp sau, hãy ngừng giai đoạn khám phá và tiến đến khai thác mô hình đã được khẳng định.

◆ Trong suốt tiến trình này, hãy cập nhật khung mô hình kinh doanh dựa trên những gì bạn học hỏi được từ việc nói chuyện với khách hàng và thử nghiệm các MVP.

Chúng tôi trình bày chi tiết về cách tiếp cận này trong Chương 4. Có hai điểm đổi mới then chốt trong mô hình này. Thứ nhất, chúng ta chấm dứt sử dụng biện pháp lập kế hoạch chi tiết để quản lý rủi ro. Thay vào đó, chúng ta tìm khách hàng và tiến hành các thử nghiệm có chi phí thấp để khám phá xem liệu mô hình kinh doanh hay sản phẩm dự kiến của chúng ta có thực sự đem lại giá trị cho họ hay không. Thứ hai, thay vì chỉ xây dựng một kế hoạch, chúng ta thực hiện lặp đi lặp lại hàng loạt các thử nghiệm để tìm ra một sản phẩm phù hợp với thị trường, bởi chúng ta hiểu rằng trong các điều kiện bất trắc, ý tưởng đầu tiên rất nhiều khả năng sẽ không đem lại kết quả.

Lập luận phản đối phổ biến đối với những nguyên tắc này là những thử nghiệm như thế có lẽ không thể đại diện cho một sản phẩm hoàn chỉnh. Sự phản đối này dựa trên sự hiểu lầm về cách đánh giá. Mục đích của việc đánh giá không phải là giành được sự chắc chắn mà là để giảm tính bất trắc. Nhiệm vụ của một cuộc thử nghiệm là thu thập những dữ liệu quan sát giúp giảm mức độ không chắc chắn. Nguyên tắc then chốt phải luôn ghi nhớ là: Khi mức độ không chắc chắn của một biến số nào đó cao thì chúng ta lại chỉ cần rất ít thông tin để giúp làm giảm đáng kể sự không chắc chắn đó.

LƯU Ý

Định nghĩa về sự đánh giá

Sự đánh giá: Định lượng mức độ giảm thiểu sự không chắc chắn dựa trên một hoặc nhiều hoạt động quan sát.

Định nghĩa này dường như có vẻ như đi ngược lại với trực giác nếu bạn không có kinh nghiệm thực hiện các thử nghiệm trong môi trường khoa học. Trong khoa học thực nghiệm, kết quả của một đánh giá không bao giờ chỉ đơn giản là một giá trị riêng lẻ. Trên thực tế, đó là một sự phân bổ xác suất thể hiện hàng loạt các giá trị tiềm năng như được biểu thị trong Hình 3-2. Đặc điểm của đầu tư vào đánh giá trong môi trường khoa học là nhằm giảm sự không chắc chắn của chúng ta về giá trị thực sự của một con số nào đó. Như vậy, cụ thể, nếu chúng ta sử dụng những con số chính xác (đối lập với việc ước lượng chừng mực) để giải thích những đánh giá của mình, chúng ta đang tự đặt mình vào tình trạng thất bại: Cơ hội chúng ta hoàn thành hạn 6 tháng trong tương lai chính xác vào ngày đó là gần như bằng 0.

Hình 3-2. Độ chuẩn xác và độ chính xác

Xây dựng một sản phẩm khả thi tối thiểu (MVP) có thể được coi là cách thực hiện một hoạt động đánh giá với chi phí tương đối thấp nhằm làm giảm mức độ không chắc chắn về các thông số then chốt của chúng ta. Vì vậy, MVP là khoản đầu tư tốt. Về căn bản, việc cùng lúc hình thành một kế hoạch kinh doanh và đặt ra các yêu cầu cho một sáng kiến quan trọng phải mất đến hàng tuần hoặc hàng tháng trong môi trường doanh nghiệp. Trong cùng khoảng thời gian đó, theo mô hình Khởi nghiệp Tinh gọn, chúng ta có thể thực hiện nhiều thử nghiệm khác nhau, thu thập thông tin từ các khách hàng thực và cho ra đời một kế hoạch tốt hơn, đã được kiểm thử và dựa trên những bằng chứng rõ ràng. Chúng ta hãy xem xét sự khác biệt giữa hai cách tiếp cận này khi cần đưa ra một quyết định đầu tư như được thể hiện trong Bảng 3-1.

Bảng 3-1. Vòng đời sản phẩm truyền thống và Vòng đời Khởi nghiệp Tinh gọn

Như được thảo luận trong Chương 2, một nhân tố quan trọng cho thành công của cách tiếp cận Khởi nghiệp Tinh gọn là hạn chế quy mô của nhóm khám phá và các nguồn lực dành cho họ (bao gồm cả thời gian). Điều này khuyến khích mọi người sáng tạo và tập trung vào học hỏi thay vì theo đuổi các giải pháp “hoàn hảo”. Không có phần thưởng cho vẻ tao nhã của thiết kế phần mềm hay độ bao phủ kiểm thử tự động⁵ trong một MVP – càng gọn gàng càng tốt, miễn là chúng ta có thể thu thập các thông tin cần thiết. Nhiều kinh nghiệm đáng nhớ mà các nhà Khởi nghiệp Tinh gọn chia sẻ cho thấy những cách làm tắt thông minh mà họ đã thực hiện khi theo đuổi tiến trình tiếp nhận những kiến thức được kiểm định.

⁵ Độ bao phủ kiểm thử (test coverage): Chỉ tỷ lệ được kiểm thử trong quá trình kiểm tra ý tưởng/sản phẩm/khái niệm. (BTV)

Dĩ nhiên sẽ có câu hỏi hợp lý là: Cứ cho rằng phát triển sản phẩm thực ra là một dạng khám phá, chúng ta nên dùng bao nhiêu thời gian và tiền bạc cho quá trình tiếp nhận những kiến thức được kiểm định? Lý thuyết trò chơi thực sự cho chúng ta công thức về giá trị thông tin kỳ vọng (Expected value of information – EVI). EVI cho chúng ta giới hạn lớn hơn về việc chúng ta nên sẵn sàng chi bao nhiêu để thu thập được những thông tin còn nghi ngờ. Nếu chi phí của việc thực hiện một hoạt động đánh giá thấp hơn nhiều so với EVI (ví dụ như thấp hơn 10 lần) thì rõ ràng nên thực hiện hoạt động đánh giá đó. Như vậy, dự án đang thực hiện càng rủi ro và đắt đỏ bao nhiêu thì giá trị bạn nhận được từ khoản đầu tư của mình bằng việc theo đuổi cách tiếp cận Khởi nghiệp Tinh gọn càng lớn bấy nhiêu.

LƯU Ý

Giá trị thông tin kỳ vọng (EVI)

Hubbard định nghĩa giá trị thông tin như sau: “Nhìn chung, giá trị thông tin bằng cơ hội sai lầm nhân với chi phí sai lầm. Chi phí sai lầm – đó là những mất mát nếu quyết định của bạn không có giá trị – được gọi là chi phí cơ hội. Lấy một ví dụ đơn giản, giả dụ bạn đang cân nhắc đầu tư 1 triệu đô-la vào một hệ thống mới. Nó hứa hẹn mức thực thu 3 triệu đô-la sau ba năm. (Để dễ hiểu, đó sẽ là một thương vụ thành công tuyệt đối hoặc một quả “bom tấn”.) Nếu bạn đầu tư nhưng hệ thống thất bại, chi phí sai lầm của bạn là 1 triệu đô-la. Nếu bạn quyết định không đầu tư nhưng lẽ ra nên đầu tư thì chi phí sai lầm của bạn là 3 triệu đô-la. Khi nhân chi phí cơ hội với cơ hội sai lầm, chúng ta nhận thiệt hại cơ hội kỳ vọng (Expected opportunity loss – EOL). Tính toán giá trị thông tin tập trung vào việc xác định xem nó sẽ làm giảm bao nhiêu EOL.

Trên thực tế, thành công của một sản phẩm hiếm khi có kết quả nhị phân⁶. Trở lại với ví dụ ROI dự tính cho một đề xuất kinh doanh được mô tả trong Hình 3-1, chúng ta tính được EOL bằng cách tính diện tích phần tối màu của đường cong, nơi thể hiện các kịch bản mất tiền khi đầu tư. Nói cách khác, chúng ta kết luận ROI ở mỗi điểm nhân với xác suất của kết quả đó. Giả dụ rằng chúng ta có thông tin hoàn chỉnh về kết quả chính xác của ROI, điều đó toàn toàn có giá trị bằng với EOL mà chúng ta vừa tính toán. Bởi vì một MVP về cơ bản sẽ cung cấp thông tin hoàn chỉnh ít hơn, EOL cho phép sử dụng nhiều yếu tố hơn trên hành trình khám phá một sản phẩm phù hợp với thị trường.

⁶ Binary outcome: Là một thuật ngữ chung về việc chỉ có hai kết quả khả dĩ trong một tình huống nhất định. (ND)

ÁP DỤNG CÁCH TIẾP CẬN KHỞI NGHIỆP TINH GỌN NGAY BÊN TRONG DOANH NGHIỆP

Việc sử dụng mô hình Khởi nghiệp Tinh gọn không chỉ giới hạn trong phát triển sản phẩm mới. Nó có thể được áp dụng vào bất kỳ loại nhiệm vụ mới nào trong môi trường doanh nghiệp, bao gồm cả việc thay thế các hệ thống, xây dựng các công cụ và sản phẩm nội bộ, đổi mới tiến trình và đánh giá phần mềm thương mại bán sẵn (COTS). Trong tất cả các trường hợp, chúng ta bắt đầu bằng việc nêu ra kết quả mong muốn đạt được với khách hàng có thể đo lường được. Chúng ta có thể xác định mục tiêu đối với các khách hàng trực tiếp trong từng giai đoạn, ví dụ như những đồng nghiệp sẽ sử dụng công cụ, tiến trình hay COTS đó. Ví dụ, đối với một công cụ tự động hóa kiểm thử nội bộ, chúng ta có thể đặt mục tiêu giảm thời gian thực hiện cho quá trình kiểm thử hồi quy đầy đủ xuống còn 8 giờ.

Để nhận định có đúng là chúng ta đã có một sản phẩm phù hợp với thị trường hay không, hãy tìm một khách hàng sẵn lòng hợp tác điều chỉnh hệ thống, công cụ, tiến trình hoặc phần mềm mới. Đây là một bước quan trọng thường bị các doanh nghiệp bỏ qua. Thực tế, đối với các công cụ nội bộ, người ta thường ra lệnh cho nhân viên dùng – một chính sách thảm họa gây lãng phí rất lớn, khiến người dùng không hài lòng và tạo ra rất ít giá trị cho tổ chức. Tiến trình tìm kiếm khách hàng và chỉ ra một vấn đề thực sự mà khách hàng sẵn sàng chi trả để bạn giải quyết nó (ngay cả nếu việc trả công là bằng thời gian và thông tin phản hồi chứ không phải là tiền bạc) – từ đó giúp bạn tìm ra một sản phẩm phù hợp với thị trường – là điều quan trọng đối với việc phát triển các công cụ bên trong, theo đuổi COTS hoặc thay thế các hệ thống nội bộ. Ra lệnh cho nhân viên sử dụng một giải pháp cụ thể gây khó khăn hơn nhiều cho việc thu thập thông tin phản hồi về việc liệu giải pháp đó có thực sự đem lại giá trị hay không.

Khi chọn được một nhóm tiên phong, chúng ta thiết kế và xây dựng một MVP. Sản phẩm này có thể là nguyên mẫu cho một công cụ được thiết kế chỉ để giúp một nhóm hoặc giúp thực thi gói COTS nhằm giải quyết vấn đề chỉ của một nhóm hoặc của một tiến trình kinh doanh đơn lẻ cho nhóm đó. Phần khó khăn nhất ở đây là hạn chế quy mô sản phẩm đến chừng mực có thể giải quyết một vấn đề thực tế nhưng đem lại giá trị trong khoảng nhiều ngày hoặc nhiều tuần, chứ không phải nhiều tháng. Điều tồi tệ nhất mà chúng ta có thể mắc phải là thiết kế một công cụ hay chiến lược tự cho là hoàn hảo nhưng lại không liên tục đem lại giá trị cho người dùng thực và cũng không tiến hành thu thập phản hồi của họ trong suốt tiến trình đó. Điều quan trọng là phải thực hiện nghiêm túc việc lập khung thời gian cho hoạt động này, đồng thời tập trung vào việc giải quyết vấn đề thực tế và cấp bách càng sớm càng tốt.

Thước đo thành công – và liệu chúng ta có nên tiếp tục hay không – là liệu khách hàng có thấy MVP đủ tốt và lựa chọn sử dụng nó hay không và liệu chúng ta có thực sự thỏa mãn kết quả mong muốn đạt được với khách hàng hay không. Nếu không, chúng ta cần chuyển hướng và trở lại từ đầu.

CÁC NGUYÊN TẮC KHÁM PHÁ

Trong Chương 1, chúng ta đã mô tả cách mà các nhóm nhỏ và có động lực tốt có thể đánh bại các đối thủ lớn hơn, được huấn luyện tốt hơn trong một cuộc chiến được gọi là chiến tranh cơ động. “Sự phá vỡ” (disruption) là một từ hiện phổ biến đến mức nhàm chán, nhưng trong bối cảnh chiến tranh cơ động, người chủ trương chính của ý tưởng phá vỡ tiến trình ra quyết định của đối thủ là Đại tá John Boyd thuộc Không quân Mỹ. Trong sự nghiệp phi công và hướng dẫn bay, Boyd nổi tiếng vì luôn khẳng định ông có thể chiến thắng bất kỳ cuộc không chiến nào – từ một vị thế bất lợi – trong vòng 40 giây. Ông cũng nổi tiếng với vai trò người đồng sáng tạo thuyết Năng lượng-Khả năng cơ động dành cho các hoạt động trên không, làm động lực cho việc thiết kế máy bay tiêm kích F-16. Tuy nhiên, sáng tạo nổi tiếng của ông là “chu trình OODA”, một mô hình (thể hiện trong Hình 3-3) về cách tương tác của con người với môi trường của họ, tạo nên nền tảng cho thuyết chiến tranh cơ động của Boyd. OODA là chữ viết tắt của Observe, Orient, Decide, Act (Quan sát, Định hướng, Quyết định và Hành động), bốn loại hoạt động tạo nên một chu trình hoàn chỉnh.

Hình 3-3. Chu trình OODA

Một nhận thức sai lầm phổ biến (chủ yếu là của những người không hiểu biểu đồ này) là các hoạt động trên được tiến hành lần lượt theo một chu trình, và bạn đạt đến “sự phá vỡ” bằng cách tiến hành chu trình nhanh hơn đối thủ. Có hai điểm thiếu sót quan trọng ở cách hiểu này. Thứ nhất, trên thực tế, cả con người và các tổ chức đều thực hiện đồng thời các hoạt động này và nắm bắt nhiều thông tin phản hồi cũng như thông tin mới từ mỗi hoạt động. Thứ hai, trì hoãn việc đưa ra quyết định cho đến phút chót thường sẽ có lợi hơn.

Để thực sự hiểu được biểu đồ, chúng ta phải bắt đầu với Định hướng. Boyd nhận thức rằng Quan sát, Quyết định và Hành động của chúng ta đều phụ thuộc vào Định hướng hiện tại. Ngược lại, Định hướng được quyết định bởi hàng loạt các yếu tố phức tạp bao gồm gen di truyền, thói quen, kinh nghiệm của chúng ta và cả môi trường văn hóa mà chúng ta sinh trưởng và đang tồn tại cũng như những thông tin mà chúng ta phải xử lý. Điểm thứ hai cần phải lưu ý về biểu đồ này là có hai cơ chế ảnh hưởng: Một là các vòng lặp phản hồi⁷ và vòng lặp nạp trước⁸, hai là “định hướng và kiểm soát ngầm” tức IGT⁹.

⁷ Vòng lặp phản hồi: Thuật ngữ chỉ tình huống trong đó một phần đầu ra của một tình huống được dùng làm đầu vào cho một tình huống khác. (BTV)

8 Vòng lặp nạp trước: Ngược lại với vòng lặp phản hồi, vòng lặp nạp trước xảy ra khi đầu ra của một tình huống sau được dùng làm đầu vào của tình huống trước. (BTV)

9 Implicit Guidance and Control là một phản ứng vật lý có kế hoạch nhưng vô thức đối với một mối đe dọa mà các nhà tâm lý thường gọi là “phản ứng tự động có rèn luyện”. (ND)

Các nhà tâm lý cho rằng hành động của chúng ta có thể được hình thành hoặc là bởi hoạt động IGT hoặc là bởi thông tin nạp trước từ một quyết định có ý thức. Hoạt động IGT trong con người do một hệ thống trong não, được gọi là Hệ thống 1, xác định. Hệ thống này “hoạt động tự động và nhanh chóng mà cần rất ít hoặc hoàn toàn không cần nỗ lực và cũng không có ý thức về việc kiểm soát tự nguyện”. Các quyết định có ý thức được thực hiện bởi Hệ thống 2 – hệ thống “tập trung sự chú ý vào các hoạt động thần kinh đầy nỗ lực, bao gồm những tính toán phức tạp. Các hoạt động của Hệ thống 2 thường gắn với kinh nghiệm chủ quan của sự lựa chọn và sự tập trung”. Tương tự như vậy, IGT ảnh hưởng đến cách chúng ta quan sát sự vật, ví dụ như xu hướng bỏ qua những thông tin trái với niềm tin của chúng ta (gọi là thiên kiến xác nhận).

Ở cấp độ tổ chức cũng có những biểu hiện của cả hai cơ chế trên. Xét về hành động, các tổ chức sử dụng cơ chế định hướng và kiểm soát tuyệt đối khi họ đưa ra quyết định bằng các mệnh lệnh phi tập trung và Yêu cầu Nhiệm vụ, dựa vào nhận thức chung về mục đích cùng với sự gắn bó trong toàn tổ chức để đảm bảo mọi người hành động vì lợi ích của tổ chức. Tuy nhiên, một số hành động (đặc biệt liên quan đến việc tuân thủ) phải được thực hiện bằng cơ chế nạp trước rõ ràng.

Cơ chế định hướng và kiểm soát ngầm cũng chi phối cách quan sát của các tổ chức. Các nền văn hóa năng suất10 tạo ra các hệ thống giám sát và những biểu hiện rõ ràng để giúp mọi người trong toàn tổ chức có thể nhanh chóng đánh giá những thông tin liên quan – từ đó có thể làm thay đổi trong định hướng của họ. Những thay đổi về định hướng sẽ thúc đẩy chúng ta cập nhật những gì chúng ta đánh giá được và cách thức lưu hành thông tin trong tổ chức. Trong các nền văn hóa quan liêu áp chế, những đánh giá được sử dụng dưới dạng kiểm soát, và mọi người tìm cách che giấu những thông tin có thể dẫn đến việc thách thức những quy tắc, chiến lược và cấu trúc quyền lực hiện có. Deming nói: “Ở đâu có sự sợ hãi, ở đó bạn sẽ nhận được những con số không chính xác.”

¹⁰ Văn hóa tổ chức được chia thành ba loại: Nền văn hóa năng suất (generative culture) mang tính tích cực, hướng đến hiệu năng; nền văn hóa quan liêu (bureaucratic culture) mang tính tiêu cực, đề cao nguyên tắc; nền văn hóa áp chế (pathological culture) mang tính tiêu cực, đề cao quyền lực. (BTV)

Khi Boyd nói về “vận hành bên trong” một chu trình OODA của đối thủ, ông hàm ý hiểu biết về chu trình của đối thủ và tác động của nó đến hành động của họ. Sau đó, bạn có thể sử dụng những hiểu biết đó để chống lại họ.

Quy trình này rất đơn giản: Một tổ chức sử dụng hiểu biết tốt hơn và nhận thức rõ ràng hơn về điều kiện diễn ra để đối phó với đối thủ của mình. Họ thực hiện những hành động phù hợp với kỳ vọng của đối thủ, điều mà Boyd, trước đó là Tôn Tử, gọi là Chính¹¹ – các lực lượng chính thống. Khi tổ chức đó cảm nhận (từ kinh nghiệm trước đây, bao gồm cả việc huấn luyện) rằng thời gian đã chín muồi, nó sẽ đưa ra Kỳ – các lực lượng phi chính thống, tức là những hành động bất ngờ và nhanh chóng. Lý do chính để sử dụng tính định hướng ngầm khi can dự với các đối thủ là những hướng dẫn công khai – ví dụ như các văn bản mệnh lệnh – sẽ mất quá nhiều thời gian. Như Boyd bình luận: “Ý tưởng chính là phải nhấn mạnh tính ngầm so với tính công khai để giành lấy sự bất đối xứng có lợi khi có sự bất đồng và chênh lệch về thời gian (ví dụ, thời gian của chúng ta ít hơn của các đối thủ) để trở nên ưu việt hơn trong quá trình định hình và điều chỉnh thích nghi với các hoàn cảnh.”

¹¹ Chính - Kỳ: Quan điểm được Tôn Tử nêu trong Binh pháp Tôn Tử, theo đó ông cho rằng quân đội có hai loại quân là Chính (tức lực lượng trực tiếp và rõ ràng) và Kỳ (tức các lực lượng ngầm, gián tiếp, bất ngờ, phi chính thống). (BTV)

Mô hình OODA cũng có thể được áp dụng khi thu hút khách hàng: “Thay vì làm họ ngạc nhiên – gây sốc – rồi khai thác, như trong chiến tranh và nghệ thuật quân sự, mô hình Chính/Kỳ có thể là gây ngạc nhiên-yêu thích-hào hứng-và trở thành khách hàng thân thiết. Apple đã chơi rất tốt trò chơi này, “Theo đuổi sự tán thưởng!” như Tom Peter từng miêu tả.

Boyd gọi quá trình định hướng và kiểm soát ngầm bên trong một tổ chức, quyết định bởi nền văn hóa và nhận thức cũng như các tiến trình thể chế hiện tại của nó, là danh mục nguồn. Chúng ta đã thảo luận cách các tổ chức áp dụng danh mục nguồn hiện có để cạnh tranh với đối thủ, nhưng để cải thiện năng lực và tránh bị đổ vỡ, chúng ta phải không ngừng sáng tạo danh mục nguồn mới của chính mình. Việc này có thể được thực hiện dưới dạng cải thiện tiến trình, phát triển các sản phẩm hiện có hoặc sáng tạo thương vụ và sản phẩm mới. Chu trình này cũng được trình bày trong mô hình OODA tại Hình 3-4.

Hình 3-4. Sáng tạo danh mục nguồn mới

Chu trình sáng tạo danh mục nguồn ít nhiều giống như việc trình bày phương pháp khoa học, trong đó chúng ta tạo ra các giả thiết mới dựa trên sự quan sát và các yếu tố tổng hợp khác, thiết kế các thử nghiệm để kiểm thử những giả thiết này và sau đó cập nhật hoặc loại bỏ các triết lý của mình (những gì đã tạo nên một phần định hướng của chúng ta) dựa trên các kết quả thử nghiệm. Sau đó chu trình này sẽ truyền cảm hứng cho chu trình xây dựng-đánh giá-học hỏi của Eric Ries (Hình 2-4) thể hiện cách tạo ra danh mục nguồn mới dưới dạng các mô hình kinh doanh, sản phẩm và tính năng mới. Chu trình xây dựng-đánh giá-học hỏi có vẻ dễ hiểu, nhưng lại khó được chấp nhận trên thực tế vì nó kết hợp một cách tiếp cận khoa học (xây dựng để học hỏi) với tư duy kỹ thuật (học hỏi để xây dựng).

Đối với việc cải thiện tiến trình (thảo luận tại Chương 6) và thay đổi nền văn hóa của tổ chức (thảo luận tại Chương 11), chúng ta có thể sử dụng một chu trình có tên là vòng tròn Deming như Hình 3-5.

Hình 3-5. Vòng tròn Deming

Chìa khóa cho thành công của các vòng tròn này (và phương pháp khoa học nói chung) là sử dụng chúng một cách hệ thống và liên tục. Sử dụng chúng một cách có hệ thống có nghĩa là dùng chúng làm công cụ phổ quát để khám phá tất cả các loại rủi ro, đảm bảo rằng chi phí cho việc thực hiện một thử nghiệm tương xứng với giá trị thông tin mà chúng ta sẽ thu nhận được. Áp dụng chúng một cách liên tục có nghĩa là thực hiện chúng càng thường xuyên càng tốt (như Mike Roberts nói: “Liên tục có nghĩa là thường xuyên hơn nhiều so với bạn nghĩ”), tập trung vào việc hoàn thành chu trình trong khoảng thời gian ngắn nhất có thể. Câu hỏi quan trọng nhất trong giai đoạn hình thành danh mục nguồn là: Chúng ta có thể học hỏi nhanh đến mức nào? Mặc dù chúng ta có thể không ngay lập tức phổ biến kết quả công việc của mình ra khắp thế giới – vì thời điểm bạn ra mắt sản phẩm là một vấn đề chiến lược – nhưng chúng ta nên học hỏi và kiểm thử những giả định của mình với người dùng thực càng thường xuyên càng tốt.

Khi mọi người trong tổ chức được huấn luyện để sử dụng cách tiếp cận khoa học trong công việc thường nhật, chúng ta hiểu rằng mình đã xây dựng được một nền văn hóa giàu sinh lực. Chúng ta giành được điều này bằng cách thực hiện các tiếp cận thử nghiệm cho đến khi trở thành thói quen, một phần vốn danh mục của chúng ta, bằng cách sử dụng phương pháp Kata Cải tiến được mô tả trong Chương 6. Điều này cho phép một tổ chức điều chỉnh để thích nghi nhanh chóng với môi trường đang thay đổi. Toyota gọi việc đó là “kiến tạo con người trước khi kiến tạo những chiếc xe ô tô”.

QUẢN LÝ KHOA HỌC SO VỚI PHƯƠNG PHÁP KHOA HỌC

Điều quan trọng là phải phân biệt giữa Quản lý Khoa học của Taylor, được mô tả trong Chương 1, và Cách Tiếp cận Thử nghiệm mà chúng ta mô tả ở đây. Trong Quản lý Khoa học, ban quản lý, những người làm việc theo chức năng và ít nhiều có xu hướng cứng nhắc, phụ trách việc phân tích tình hình và đưa ra quyết định. Trong Cách Tiếp cận Thử nghiệm, nhiệm vụ của ban lãnh đạo và ban quản lý là thiết kế, phát triển và vận hành một hệ thống trong đó mọi nhân viên có kỹ năng và nguồn lực cần thiết để thực hiện các thử nghiệm của riêng họ, vì vậy hoặc tự mình hoặc cùng với những nhân viên khác, họ học hỏi, phát triển và nâng cao kiến thức cho mình.

Theo Bảng 3-2, việc áp dụng phương pháp khoa học để phát triển sản phẩm khác biệt căn bản với cách tiếp cận truyền thống dựa trên kế hoạch và đòi hỏi các kỹ năng cũng như thái độ rất khác nhau. Không phải các vòng đời dự án truyền thống có gì đó không tốt. Trên thực tế, chúng có thể phát huy hiệu quả trong các dự án có sản phẩm đã được sản xuất nhiều lần trước đó và người ta đã hiểu rõ những rủi ro của chúng. Nhưng phương pháp quản lý dự án truyền thống là mô hình sai lầm trong các điều kiện không chắc chắn như là phát triển sản phẩm mới hay bất kỳ loại phát triển phần mềm khách hàng nào.

Bảng 3-2. Lập kế hoạch dự án truyền thống và Khởi nghiệp Tinh gọn

Những rào cản lớn nhất đối với việc áp dụng cách tiếp cận khoa học trong phát triển sản phẩm và thay đổi tổ chức chính là nền văn hóa và tổ chức, như chúng ta thảo luận trong Phần IV. Trong nhiều trường hợp, các tổ chức thường không bao giờ áp dụng cách tiếp cận dựa trên thử nghiệm và thiếu những kỹ năng, kinh nghiệm để thực hiện điều đó. Trong bối cảnh phát triển sản phẩm, việc tìm hiểu cách thiết kế, thực hiện các thử nghiệm và phân tích dữ liệu đều rất khó khăn và có tầm quan trọng sống còn – tuy nhiên, chúng không phải là một phần cốt lõi của chương trình giảng dạy trong nhiều chương trình hoặc khóa học MBA về thiết kế và phân tích phần mềm. Trong các tổ chức quan liêu và áp chế, cách tiếp cận thử nghiệm cũng có thể thách thức cấu trúc quyền lực và các quy tắc văn hóa hiện tại.

KẾT LUẬN

Chúng ta đã xây dựng những nền tảng của cách tiếp cận khoa học trong khám phá những công việc mới, bất kể đó là các mô hình kinh doanh hay các sản phẩm mới, công việc nội bộ của doanh nghiệp như là thiết kế các công cụ mới hoặc thông qua các tiến trình mới. Khi chúng ta nhận thức giống nhau về rủi ro, đánh giá và sự không chắc chắn, chúng ta có thể áp dụng các nguyên tắc và biện pháp của Khởi nghiệp Tinh gọn. Việc đó sẽ cung cấp phương pháp ưu việt về quản lý rủi ro của quyết định đầu tư hơn là các hoạt động lên kế hoạch truyền thống.

Khả năng cạnh tranh của chúng ta dựa vào việc xây dựng được định hướng chung cho toàn tổ chức và giúp mọi người có thể làm việc để không ngừng sáng tạo thực hiện danh mục nguồn mới thông qua tiến trình thử nghiệm. Những hoạt động này giúp chúng ta phát hiện và phân tích những thay đổi trong môi trường của mình một cách hiệu quả hơn, giúp tìm hiểu các tiến trình ra quyết định của các tổ chức khác, và giúp ta hành động – để phục vụ khách hàng tốt hơn và kiến tạo môi trường của mình. Mô hình OODA của Boyd cho thấy sự điều chỉnh đối với môi trường của chúng ta là một tiến trình liên tục và tiếp diễn đối với các tổ chức cũng như con người.

Câu hỏi dành cho độc giả:

◆ Tổ chức hay bộ phận của bạn thiết lập mô hình rủi ro đầu tư trong kế hoạch kinh doanh như thế nào? Dựa trên những dữ liệu nào?

◆ Đâu là những biến số trong kế hoạch có giá trị thông tin cao nhất? Các bạn đã đánh giá những gì để giảm tính không chắc chắn của những biến số này?

◆ Bạn tự tin ra sao về việc mọi người sẽ thấy những gì bạn đang làm là có giá trị? Bạn có bằng chứng gì để chứng minh cho quyết định của mình?

◆ Bạn có thường xuyên kiểm thử các sản phẩm mà bạn đang xây dựng với các khách hàng dự tính không? Kết quả, bạn đã quyết định thay đổi những gì?

Chương 4Khám phá tính bất trắc để phát hiện các cơ hội

Chính bóng tối đã tạo ra bóng đèn. Chính sương mù đã tạo ra la bàn. Chính sự khao khát đã thúc đẩy chúng ta khám phá.

− VICTOR HUGO

Trong chương này, chúng tôi sẽ bàn đến các biện pháp thực hiện các nguyên tắc, được thảo luận tại Chương 3, về việc khám phá các cơ hội trong điều kiện vô cùng bất trắc, đặc biệt liên quan đến các mô hình kinh doanh hoặc sản phẩm mới. Chúng tôi giới thiệu khái niệm Khám phá để mô tả cách vạch ra một giả thiết kinh doanh nhanh chóng để tạo ra nhận thức chung về một vấn đề và thu hút các bên liên quan trong toàn tổ chức để đạt được sự ủng hộ đối với tầm nhìn của chúng ta.

Chúng tôi sẽ chia sẻ những công cụ và kỹ thuật cụ thể để xác định và kiểm thử các giả thiết một cách an toàn nhằm giải quyết những vấn đề kinh doanh thực sự đã được phát hiện và công nhận trong tiến trình phát triển khách hàng.

Sau đó, chúng tôi sẽ mô tả cách sử dụng phương pháp tiếp cận thử nghiệm có tính nguyên tắc, khoa học và dựa trên bằng chứng để trả lời cho câu hỏi cơ bản – không phải là “chúng ta có thể tạo ra nó không?” mà là “chúng ta có nên tạo ra nó không?”

Chúng tôi cũng sẽ thảo luận cách kiểm thử các giả định rủi ro nhất trong giả thiết của chúng ta và tạo ra các dữ liệu kinh nghiệm để hỗ trợ quyết định chuyển hướng, kiên trì tiếp tục hay dừng lại bằng việc tạo ra các thử nghiệm thất bại-an toàn¹, sử dụng các MVP. Mục đích của chúng ta là dựa nhiều hơn vào bằng chứng, chứ không phải vào ngành khoa học viễn tưởng, đưa ra các quyết định đầu tư và quản lý danh mục nguồn. Chúng ta sẽ tận dụng các cơ hội khả dĩ bằng cách làm điều đúng đắn vào đúng thời điểm và chấm dứt việc lãng phí thời gian của mọi người vào những ý tưởng không có giá trị.

1 Thử nghiệm thất bại-an toàn (safe-to-fail): Là những hoạt động mang tính thử nghiệm ở quy mô vừa phải, có tính đến khả năng thất bại. (BTV)

KHÁM PHÁ

Khám phá là một chuỗi hành động nhanh chóng, có thời hạn và lặp đi lặp lại giúp tích hợp những biện pháp và các nguyên tắc tư duy kế hoạch và Khởi nghiệp Tinh gọn. Chúng ta tăng cường áp dụng các hành động đó ngay từ đầu giai đoạn khám phá một sáng kiến mới.

Trong cuốn Lean UX: Applying Lean Principles to Improve User Experience (tạm dịch: UX tinh gọn: Áp dụng các nguyên tắc tinh gọn để cải thiện trải nghiệm người dùng), Jeff Gothelf và Josh Seiden cho biết: “Tư duy thiết kế thực hiện cách tiếp cận tập trung vào giải pháp để giải quyết vấn đề, làm việc tập thể để lặp đi lặp lại một con đường luân chuyển vô tận hướng đến sự hoàn hảo. Nó hướng đến các mục tiêu sản phẩm qua các bước đi tìm ý tưởng cụ thể, làm mẫu, thực thi để thu hút sự chú ý của mọi người đối với giải pháp phù hợp với nó.”

Bằng việc kết hợp các nguyên tắc tư duy thiết kế với các biện pháp Khởi nghiệp Tinh gọn, chúng ta có thể xây dựng một chu trình phản hồi liên tục với người dùng và khách hàng thực đồng thời phát triển thành vòng phát triển của chúng ta. Nguyên tắc là đầu tư nỗ lực tối thiểu để nhận được lượng hiểu biết tối đa và sử dụng kết quả các thử nghiệm làm cơ sở ra quyết định chuyển hướng, tiếp tục hay dừng lại.

LƯU Ý

Khách hàng và người dùng

Mặc dù chúng ta thường sử dụng hoán đổi các thuật ngữ này, nhưng sẽ có ích nếu chúng ta biết phân biệt giữa khách hàng của một sản phẩm hay dịch vụ, người trả giá cho nó hoặc đầu tư vào sự phát triển của nó, với người dùng. Người dùng không trả giá cho sản phẩm, nhưng họ đóng góp lượng giá trị lớn cho tổ chức tạo ra sản phẩm, và thường cho chính sản phẩm đó (các mạng xã hội là một ví dụ rõ ràng). Trong một doanh nghiệp, mọi người được yêu cầu sử dụng các hệ thống cụ thể để hoàn thành nhiệm vụ của mình, và các tổ chức phải gánh chịu những hậu quả tiêu cực thực sự khi các hệ thống đó khó vận hành. Điều quan trọng là phải kéo theo cả khách hàng và người dùng, coi đó là những bên liên quan then chốt trong quá trình cùng sáng tạo sản phẩm, dịch vụ hoặc các cơ hội cải tiến.

Trong giai đoạn Khám phá, chúng ta tạo ra một môi trường phối hợp và toàn diện cho một nhóm nhỏ liên chức năng và đa kỹ năng để khám phá một thương vụ, sản phẩm hay cơ hội cải tiến. Nhóm này nên được tạo điều kiện đầy đủ để tăng tối đa tốc độ học hỏi và hiệu quả của việc ra quyết định trong thời gian thực. Nhóm này phải có quyền sở hữu quy trình phân phối sản phẩm và phải được trao quyền ra các quyết định cần thiết để đáp ứng các mục tiêu của sáng kiến.

Khi thành lập một nhóm, quan trọng là phải giữ cho nhóm đó ở quy mô nhỏ, chỉ gồm những người có năng lực cần thiết để khám phá phạm vi vấn đề. Các nhóm lớn thường được trang bị nghèo nàn nên không thể khám phá nhanh chóng và học hỏi với tốc độ cần thiết để đạt đến thành công. Trong khi đó, nhóm nhỏ này phải biết các ranh giới và hạn chế của họ, đồng thời có trách nhiệm can dự với người ngoài nhóm để tìm dữ liệu đầu vào và phối hợp khi phù hợp.

Các thành viên cuối cùng – và thường bị bỏ quên – của nhóm chính là các khách hàng và người dùng. Chúng ta dễ bị rơi vào bẫy khi chỉ coi họ đơn giản là một khách hàng của giải pháp mà chúng ta đưa ra. Trên thực tế, họ là những bên liên quan có vai trò quyết định. Dữ liệu đầu vào của họ là thành phần then chốt và thước đo có tính mục đích nhất để đánh giá liệu giải pháp của chúng ta có hay có thể có giá trị hay không. Với thông tin phản hồi, khách hàng và người dùng là những người đồng sáng tạo ra giá trị cho bất kỳ giải pháp nào. Các nhu cầu của họ phải luôn là trọng tâm của mọi việc mà chúng ta làm.

Xây dựng hiểu biết chung

Khi bạn muốn đóng một con tàu, đừng bắt đầu bằng việc tìm gỗ, cưa những tấm ván và phân công nhiệm vụ, mà hãy định hướng bằng trái tim của con người khao khát biển cả mênh mông và vô tận.

− TƯỞNG NHỚ ANTOINE DE SAINT-EXUPERY

Khi bắt đầu một phần việc mới, điều cần thiết là nhóm phải tạo ra một môi trường tối đa hóa khả năng thu hút mọi người tham gia. Dựa vào thông tin mà họ khám phá, mọi người học hỏi, thay đổi và cải tiến khi họ được tham gia vào một tiến trình đầy nhiệt huyết, tính tương tác và thích nghi cao.

Theo nhận định của Dan Pink trong cuốn Drive (Động lực chèo lái hành vi²), có ba yếu tố then chốt cần cân nhắc khi thành lập một nhóm với yêu cầu phải năng động và có động lực tích cực. Thứ nhất, thành công đòi hỏi phải có nhận thức chung về mục đích trong toàn nhóm. Tầm nhìn này cần phải đủ thách thức để nhóm có khao khát về một điều gì đó, nhưng cũng phải đủ rõ ràng để mọi người có thể hiểu những gì họ cần làm. Thứ hai, mọi người phải được ban lãnh đạo trao quyền làm việc một cách độc lập để đạt được các mục tiêu của nhóm. Cuối cùng, mọi người cần không gian và cơ hội để làm chủ phương pháp của mình, không phải chỉ để học cách hoàn thành công việc “đủ tốt” mà thôi.

² Đã được Alpha Books mua bản quyền vài xuất bản năm 2010. (BTV)

Tiến trình hình thành tầm nhìn này bắt đầu bằng việc giải thích rõ ràng về vấn đề mà nhóm sẽ phải nỗ lực giải quyết. Bước quan trọng này thường bị bỏ qua, hoặc chúng ta mặc định rằng mọi người đều đã biết vấn đề đó là gì. Chất lượng của việc giải thích vấn đề làm tăng khả năng của nhóm trong việc tập trung vào những thứ thực sự cần thiết và quan trọng hơn là bỏ qua những gì không cần thiết. Bằng việc phát triển nhận thức chung của nhóm về các mục đích và những gì chúng ta muốn đạt được, chúng ta cải thiện được khả năng phát hiện những giải pháp tốt hơn.

Hình 4-1. Xây dựng nhận thức chung cho nhóm

BÍ QUYẾT

Hãy học Gamestorming

Gamestorming của David Gray và những người khác, và trang Wiki ủng hộ Hãy học Gamestorming, bao gồm nhiều trò chơi khuyến khích sự tham gia và tính sáng tạo trong khi vẫn đem đến cấu trúc và sự minh bạch cho các ý tưởng tập thể, sự đổi mới và các hoạt động cải tiến.

Một trong những kỹ thuật Khám phá cơ bản là sử dụng các công cụ hữu hình, các mô hình và các vật bức xạ thông tin để giao tiếp và nắm bắt những hiểu biết mà nhóm thu nhận được. Sử dụng các mẫu đồ họa và quy trình thực hiện để thể hiện các ý tưởng giúp nhóm của chúng ta giải thích, thảo luận và phát triển các khái niệm và ý tưởng, từ đó tạo được sự đồng thuận (xem Hình 4-1). Nó cũng góp phần giúp chúng ta phi cá nhân hóa và bỏ qua các suy nghĩ ngoài lề để có thể tranh luận các ý tưởng một cách an toàn, chứ không phải là các cá nhân – giảm thiểu cái tôi, quy tắc HiPPO và các nỗ lực tiếm quyền điều hành của những người có tính cách hướng ngoại.

Khám phá tính bất trắc một cách có tổ chức Nếu muốn có những ý tưởng hay thì bạn phải có nhiều ý tưởng.

− LINUS PAULING

Khi khám phá tính bất trắc, điều quan trọng là phải bắt đầu trên diện rộng – hình thành càng nhiều ý tưởng càng tốt để nghiên cứu sơ bộ trước khi giới hạn những điểm cần tập trung trong giai đoạn khởi đầu.

Web.taisachnhanh.cloud là một hãng du lịch bán lẻ ở châu Âu, hoạt động trong một ngành công nghiệp có tính cạnh tranh cao với những công ty lớn và các doanh nghiệp khởi nghiệp đang cố gắng phá vỡ thị trường du lịch mỗi ngày. Để tồn tại, công ty cần cải cách nhanh hơn và thông minh hơn các đối thủ cạnh tranh. Họ đưa khách hàng thành một phần của tiến trình cải cách. Trong hai ngày, họ tổ chức các hội thảo đồng sáng tạo và đã hình thành 80 ý tưởng mới cho các sản phẩm trực tuyến gắn với các mục đích kinh doanh của họ. Nhóm này sau đó xây dựng một bộ phận thử nghiệm cải cách ở tiền sảnh một khách sạn trong một tuần, qua đó họ nhanh chóng kiểm thử từng ý tưởng để bác bỏ hoặc khẳng định nó là một vấn đề khách hàng khả thi. Trong nhiều ngày, nhóm này đã nhận ra ba ý tưởng hàng đầu cần đầu tư thêm các nỗ lực phát triển – kết quả là số khách hàng chuyển sang sử dụng sản phẩm của họ gia tăng hơn 100%.

Tư duy dị biệt là khả năng đưa ra các ý tưởng khác biệt, duy nhất hoặc linh hoạt cho một chủ đề; tư duy tập trung là khả năng xác định một giải pháp tiềm tàng cho một vấn đề cụ thể. Chúng ta bắt đầu khám phá bằng những bài tập tư duy dị biệt được thiết kế nhằm hình thành nhiều ý tưởng để thảo luận và tranh cãi. Sau đó, chúng ta sử dụng tư duy tập trung để xác định một giải pháp khả dĩ cho vấn đề. Từ đây, chúng ta sẵn sàng để xây dựng một thử nghiệm nhằm kiểm thử ý tưởng đó (xem Hình 4-2).

Hình 4-2. Quá trình khám phá có tổ chức bằng tư duy dị biệt và tư duy tập trung

CHÚNG TA ĐANG THEO MÔ HÌNH KINH DOANH NÀO?

Các mô hình kinh doanh thường không tồn tại lâu và có xu hướng đổ vỡ do những thay đổi trong môi trường cạnh tranh, những tiến bộ về thiết kế và công nghệ cũng như những thay đổi lớn hơn về xã hội và kinh tế. Những tổ chức nào không xác định đúng mục đích, hoặc không thể nhận thức và điều chỉnh trước những thay đổi này, sẽ thất bại.

Các tổ chức có thể bị loại bỏ bởi những đối thủ cạnh tranh giải quyết được vấn đề tương tự bằng sản phẩm thay thế hoặc dịch vụ khách hàng vượt trội. Định nghĩa kinh doanh và xác định những cơ hội tương lai phải luôn bị thách thức và phát triển. Cho phép tự thỏa mãn và say sưa với thành công hiện tại là con đường nhanh nhất dẫn đến thất bại trong tương lai. Chúng ta chỉ cần trích dẫn những ví dụ như Blockbuster với Netflix hoặc HMV và Tower Records đối với iTunes, YouTube và Spotify để chứng minh cho nhận định rằng không có mô hình kinh doanh hay lợi thế cạnh tranh nào bền vững mãi mãi.

Các tổ chức chiến thắng là các tổ chức liên tục thử nghiệm và kiểm thử các giả thiết để biết giả thiết nào có hiệu quả và giả thiết nào không, tìm ra những giả thiết có thể tác động lớn đến vận mệnh của doanh nghiệp trong tương lai.

Nhận biết những khó khăn trong kinh doanh để đưa ra kế hoạch kinh doanh

Steve Blank, tác giả cuốn The Four Steps to the Epiphany (Bốn bước chinh phục đỉnh cao) và cuốn The Startup Owner’s Manual (Bách khoa toàn thư về khởi nghiệp³), nhận định:

³ Đã được Alpha Books mua bản quyền và xuất bản năm 2017. (BTV)

Một kế hoạch kinh doanh là một tài liệu thực thi mà các công ty hiện nay viết khi dự định mở rộng dây chuyền sản xuất, trong đó tính đến các đặc điểm của khách hàng, thị trường và sản phẩm. Kế hoạch này là một tài liệu hoạt động và mô tả chiến lược thực thi nhằm giải quyết những “điều đã biết” này.

Mục tiêu chính của một sáng kiến kinh doanh mới là khẳng định tính hiệu quả của giả thiết mô hình kinh doanh (lặp đi lặp lại, điều chỉnh cho đến khi đạt được mục tiêu này). Tìm kiếm và thực thi là những gì giúp phân biệt một dự án mới với một đơn vị kinh doanh đang hoạt động. Sau khi một mô hình kinh doanh được thẩm định, nên triển khai nó trên thực tế. Tại thời điểm này, dự án đó cần phải có kế hoạch hành động, dự toán tài chính và các công cụ quản lý đã được hiểu rõ khác.

Điều quan trọng là phải xem xét nhiều mô hình kinh doanh khác nhau trong giai đoạn đầu của một sáng kiến mới. Không nên theo đuổi một kế hoạch khi chưa kiểm thử giả thiết mô hình kinh doanh và phải có bằng chứng rằng chúng ta đang đi đúng hướng. Nhóm này phải xác định được những giả định rủi ro nhất trong giả thiết của chúng ta, thực hiện những thử nghiệm để kiểm thử những giả định đó và tăng lượng thông tin mà chúng ta có thể giành được nhằm làm giảm tính bất trắc.

Giả định duy nhất luôn đúng là không có kế hoạch kinh doanh nào vượt qua được những tiếp xúc đầu tiên với khách hàng.

Khung Mô hình Kinh doanh, được mô tả trong Hình 4-3, do Alex Osterwalder và Yves Pigneur cùng với 470 nhà đồng sáng tạo khác thực hiện, là một cỗ máy hữu hình thiết kế các mô hình kinh doanh. Đó là một công cụ quản lý và kinh doanh chiến lược giúp các nhóm mô tả, thiết kế, thách thức, sáng chế và chuyển hướng các mô hình kinh doanh. Thay vì viết một kế hoạch kinh doanh – một tiến trình có thể kéo dài dằng dặc, chúng ta vạch ra nhiều mô hình khả dĩ – mỗi mô hình giới hạn trong 30 phút – và dựng lên một sơ đồ minh họa.

Hình 4-3. Khung Mô hình Kinh doanh

Khung Mô hình Kinh doanh, được đăng tải trên trang web Web.taisachnhanh.cloud/canvas, đã vạch ra chín thành tố quan trọng của một mô hình kinh doanh dựa trên các khái niệm của một tổ chức:

Phân khúc khách hàng

Chúng ta dự định tạo ra giá trị cho những khách hàng nào? Đối tượng nào là khách hàng của chúng ta?

Giải pháp giá trị

Chúng ta dự định giải quyết những vấn đề nào để tạo ra giá trị cho khách hàng của mình?

Kênh kinh doanh

Chúng ta định vươn tới các khách hàng mục tiêu của mình thông qua các kênh nào?

Quan hệ khách hàng

Mỗi khách hàng của chúng ta hy vọng chúng ta tạo ra và duy trì loại quan hệ nào với họ?

Những hoạt động trọng yếu

Các hoạt động nào sẽ cần để hỗ trợ việc xác nhận giá trị của chúng ta?

Các nguồn lực chủ chốt

Nguồn lực, con người, công nghệ và sự ủng hộ nào là cần thiết đối với quá trình vận hành của một doanh nghiệp?

Những đối tác chính

Chúng ta cần xây dựng quan hệ đối tác với ai? Những ai là nhà cung cấp chính của chúng ta, chúng ta cần những ai để cung cấp các nguồn lực phụ trợ hoặc các hoạt động để xác nhận giá trị của chúng ta?

Cơ cấu chi phí

Những chi phí cố định quan trọng nhất với doanh nghiệp của chúng ta là gì?

Dòng doanh thu

Các khách hàng của chúng ta sẵn sàng trả tiền cho loại giá trị nào? Họ trả bao nhiêu và thường xuyên như thế nào?

Bằng việc đưa dần các dữ kiện cá nhân vào mô hình trên, chúng ta sẽ thấy cần xem xét bất kỳ ý tưởng tiềm năng nào trong các khối thành tố của toàn doanh nghiệp. Khi đưa hết các dữ kiện vào toàn bộ mô hình, chúng ta sẽ thấy cần suy nghĩ bằng một thái độ toàn diện về cách mà những mảnh này được ghép lại với nhau để tạo ra cơ hội lớn hơn. Một điều quan trọng mà bạn phải nhớ là mỗi khối thành tố của mô hình thể hiện một tập hợp các giả thiết và giả định đi kèm đòi hỏi phải được khẳng định để có thể chứng tỏ mô hình kinh doanh của chúng ta là đúng đắn.

Không chỉ tạo ra mô hình này, Osterwalder còn kết luận về bốn mức độ làm chủ chiến lược về cạnh tranh trong mô hình kinh doanh nhằm phản ánh mục đích chiến lược của một tổ chức:

Chiến lược mức 0

Người không hiểu chỉ tập trung vào những vấn đề về sản phẩm/ giá trị của sản phẩm chứ không phải là vấn đề về giá trị và mô hình kinh doanh.

Chiến lược mức 1

Người mới vào nghề sử dụng Khung Mô hình Kinh doanh làm bảng liệt kê những mục cần quan tâm.

Chiến lược mức 2

Những ông chủ cạnh tranh vượt trội với đối thủ nhờ một mô hình kinh doanh siêu việt hơn khi mà tất cả các khối thành tố củng cố cho nhau (ví dụ như Toyota, Walmart, Dell).

Chiến lược mức 3

Những nhà vô địch không ngừng tự mình bứt phá trong khi các mô hình kinh doanh của họ vẫn thành công (ví dụ như Apple, Amazon).

Khả năng nhận diện chiến lược mà chúng ta đang theo đuổi khi xây dựng các mô hình kinh doanh là bước đầu tiên hướng đến việc hình thành nhận thức chung về cách tiếp cận đổi mới sẽ có hiệu quả nhất nhằm giúp chúng ta đạt được mục đích của mình.

Mục tiêu chủ yếu của Khung Mô hình Kinh doanh là nhằm thể hiện giả thiết kinh doanh và làm rõ những giả định của nó để chúng ta có thể phát hiện và xác định những rủi ro chính. Các khung này cung cấp một khuôn khổ giúp mô tả các mô hình kinh doanh bằng những thuật ngữ mà mọi người đều hiểu, từ đó tạo ra ý thức sở hữu chung và hỗ trợ sự phối hợp trong toàn tổ chức. Khung Mô hình Kinh doanh khác với các khung khác được thống kê trong Bảng 4-1 ở chỗ nó không nhận định rằng một sản phẩm phù hợp với thị trường là giả thiết rủi ro nhất và cần phải kiểm thử đầu tiên.

Có một số khung được những người khác tạo ra để tập trung vào phát triển sản phẩm như được thể hiện trong Bảng 4-1.

Bảng 4-1. Minh họa ý tưởng hữu hình

Thấu hiểu khách hàng và người dùng

Điều quan trọng nhất phải nhớ là bất kỳ doanh nghiệp nào cũng không thể đạt được kết quả mong muốn nếu chỉ quanh quẩn trong những bức tường của mình. Kết quả của một giao dịch phải là có được một khách hàng hài lòng.

− PETER DRUCKER

Bất kỳ một sản phẩm hay giải pháp nào cũng chỉ thành công khi mọi người muốn sử dụng nó và thực sự muốn trả tiền để sở hữu nó. Để một nhóm bất kỳ xây dựng được một giải pháp có thể giải quyết một vấn đề hay nhu cầu thực sự, thì điều quan trọng là phải hiểu chúng ta đang nhắm tới ai và tại sao lại nhắm tới họ.⁴

⁴ Chân dung khách hàng (persona): Là kỹ thuật trong marketing, miêu tả khách hàng dựa trên các dữ liệu về nhân khẩu học, hành vi mua sắm, giá trị, mục tiêu, v.v...

NHẬN DIỆN KHÁCH HÀNG VÀ NGƯỜI DÙNG CỦA BẠN

Mỗi chân dung khách hàng1 là một đại diện của những vấn đề, những nhu cầu, những mục đích và thái độ của một nhóm khách hàng và người dùng theo giả định. Chân dung khách hàng được đánh giá dựa trên những thông tin thích đáng và hiểu biết của các nhà sáng tạo. Về bản chất, đó là tập hợp những giả định phải được kiểm thử và cải tiến trong suốt tiến trình phát triển khách hàng của chúng ta.

Khi xây dựng một chân dung khách hàng, cần nhớ những điểm sau:

• Xác định và động não rất nhanh về chân dung khách hàng ban đầu của bạn để tạo được sự gắn bó trong toàn đội.

• Liên tục tái xác định chân dung khách hàng của bạn dựa trên những bằng chứng từ các nghiên cứu về người dùng, kiểm thử và phản hồi trong chu trình phát triển khách hàng.

• Không ngừng tái liên kết chân dung khách hàng đó với tầm nhìn sản phẩm kinh doanh khi sản phẩm đó bắt đầu hình thành.

Chân dung khách hàng chỉ là điểm xuất phát mà chúng ta sử dụng để tạo ra nhận thức chung về khách hàng và người dùng. Chúng không bao giờ thực sự có tính mục đích hay kinh nghiệm. Chúng ta sử dụng chân dung khách hàng để tạo ra sự chia sẻ về các vấn đề của nhóm mục tiêu và có thể chuyển những ưu tiên cá nhân thành những gì mà chân dung khách hàng được lựa chọn đó sẽ coi là có giá trị – đó là Việc-cần-phải-hoàn thành.

Sự đồng cảm của bạn với khách hàng và người dùng là một sức mạnh thực thụ. Khi đồng cảm, chúng ta tăng cường khả năng tiếp nhận và xử lý thông tin. Sự đồng cảm về ý tưởng đòi hỏi phải có hành động thận trọng trên thực tiễn. Chúng ta phải thiết kế các thử nghiệm và các cơ hội tương tác để kết nối với khách hàng và người dùng một cách có ý nghĩa và thách thức các giả định, định kiến và thành kiến của chúng ta. Chúng ta cần nắm vai trò khách quan của một viên thanh tra và cố gắng hiểu những thách thức mà họ trải nghiệm.

Tạo ra thế cân bằng giữa sự đồng cảm với kinh nghiệm và phân tích tình huống cho phép chúng ta hiểu cảm giác và quan điểm của khách hàng và người dùng. Khi đó chúng ta có thể sử dụng hiểu biết đó để định hướng sự tìm kiếm các giả thiết về giải pháp và bắt đầu tiến trình thử nghiệm.

BÍ QUYẾT

Đi, Nhìn và Thấy

Tại các phân xưởng của công ty thiết kế IDEO, nơi nổi tiếng về việc phát minh ra con chuột Apple ban đầu, các nhóm làm việc luôn đắm mình hoàn toàn vào môi trường mà các sản phẩm hoặc dịch vụ tưởng tượng sẽ được sử dụng. Các nhà phát triển sản phẩm và dịch vụ đó nghiên cứu mọi thứ cần thiết về thị trường, quan sát và phỏng vấn những người dùng tương lai, nghiên cứu những tính năng sẽ cạnh tranh với sản phẩm mới và chuyển mọi điều mà họ học hỏi được thành các hình ảnh, mô hình và biểu đồ. Nhờ đó, họ hiểu biết về khách hàng và người dùng, kiểm thử, cải tiến hoặc bỏ qua những hiểu biết đó trong toàn bộ tiến trình phát triển tái lặp.

Tại Toyota, triết lý genchi genbutsu (“đi và thấy”) cho phép các nhà lãnh đạo xác định những nguy cơ mất an toàn hiện hữu, quan sát điều kiện máy móc và trang bị, thắc mắc về những tiêu chuẩn thực tiễn để nắm thông tin về tình hình công việc và xây dựng mối quan hệ với công nhân. Mục tiêu của genchi genbutsu là đi đến gemba (nơi làm việc) để hiểu chuỗi giá trị và các vấn đề của nó chứ không phải là nghiên cứu các báo cáo và đưa ra những bình luận hời hợt.

Tương tự như vậy, phương châm “ra ngoài nói chuyện thực sự với khách hàng” (một thuật ngữ được phổ cập bởi doanh nhân kiêm tác giả Steve Blank) là một kỹ thuật phát triển khách hàng để nhận phản hồi và tập trung những nỗ lực phát triển sản phẩm đầu tiên vào những người tiếp nhận đầu tiên thông qua những cuộc khảo sát chất lượng thường xuyên (trong đó có các bài phỏng vấn) với đa dạng các khách hàng tiềm năng.

Những người không thể tạm thời thoát khỏi vai trò và vị trí của họ hoặc không thể gạt qua một bên nhận thức và quan điểm của mình sẽ không thể hình thành sự đồng cảm với những suy nghĩ, kinh nghiệm hay tâm tư khác biệt của người khác. Khả năng lắng nghe và đặt ra những câu hỏi đúng trở thành một kỹ năng đắc lực, và những hiểu biết sâu sắc mà nó mang lại là nền tảng cho việc thử nghiệm và giải quyết vấn đề một cách hiệu quả.

Biến hiểu biết và thông tin thành lợi thế bất đối xứng

Khả năng khám phá và thu thập những hiểu biết quan trọng giữ vai trò rất cần thiết đối với các tổ chức hiệu năng cao. Trước đây, chúng ta sống trong một vũ trụ thông tin nhỏ bé với chi phí thu thập, lưu trữ và xử lý thông tin rất cao. Phong trào Dữ liệu Lớn⁵ đã cung cấp cho chúng ta công nghệ và kỹ thuật để xem xét, xử lý và liên kết những tập hợp dữ liệu lớn hiện có. Các tổ chức có thể giành được thêm giá trị từ những hiểu biết về cách thức và lý do khách hàng của họ tương tác với các sản phẩm và giải pháp mà họ đưa ra. Chúng ta có thể phát hiện những tín hiệu, dù yếu ớt, cho thấy những gì đang hoạt động hiệu quả – hoặc không hiệu quả – và sử dụng thông tin đó để cải thiện các dịch vụ hiện tại hoặc xây dựng các tính năng mới. Khi được kết hợp với nhau, phần mềm, những phân tích và dữ liệu tạo thành một trụ cột then chốt cho vốn tri thức của tổ chức.

⁵ Big data: là một thuật ngữ cho rằng việc xử lý một tập hợp dữ liệu rất lớn và phức tạp mà các ứng dụng xử lý dữ liệu truyền thống không xử lý được. (ND)

Cách tiếp cận và hiểu biết về khách hàng hiện tại là lợi thế cạnh tranh quan trọng mà các tổ chức đang hoạt động có được so với các doanh nghiệp khởi nghiệp. Các doanh nghiệp khởi nghiệp đối mặt với thách thức khi vươn lên và chiếm lĩnh thị trường do chưa có cách tiếp cận dữ liệu về những khách hàng mà thị trường đã biết đến. Mặt khác, các tổ chức đang hoạt động đã có dữ liệu thị trường và khách hàng hiện tại để có thể tái sử dụng và tạo điều kiện cho việc phát hiện những cơ hội mới.

Cụ thể, các tổ chức có thể đặt ra những câu hỏi “Tại sao khách hàng lại chấm dứt tư cách thành viên?” hoặc “Các khách hàng liên hệ với nhau như thế nào?” và tiến hành các thử nghiệm nhanh và rẻ để kiểm thử các giả thiết của mình dựa trên dữ liệu hiện có. Đây là một kỹ thuật hiệu quả nhằm ngăn chặn việc dựa vào thành kiến để ra quyết định trong tiến trình ưu tiên của chúng ta và có thể đưa ra các quyết định dựa trên dữ liệu thực tiễn.

Các phân tích dữ liệu cho phép chúng ta chuyển đổi tiến trình khám phá, tức là đánh giá xem khách hàng sử dụng các dịch vụ hiện nay ra sao, qua đó để thúc đẩy những kế hoạch tạo cơ hội cho các mô hình kinh doanh, sản phẩm hoặc dịch vụ mới.

LƯU Ý

Các công ty khai thác thông tin và phát hiện ra bí quyết của bạn bằng cách nào?

Trong cuốn The power of habit (Sức mạnh của thói quen⁶), Charles Duhigg viết: “Hầu hết các nhà bán lẻ lớn, từ chuỗi tạp hóa đến các ngân hàng đầu tư rồi đến Công ty Dịch vụ Bưu chính Mỹ, đều có một bộ phận “phân tích dự báo” với nhiệm vụ tìm hiểu không chỉ thói quen mua sắm của khách hàng mà cả các thói quen cá nhân của họ nhằm tiếp thị đến họ một cách hiệu quả hơn.”

⁶ Được Alpha Books mua bản quyền và xuất bản năm 2015. (BTV)

Target đã sử dụng những dữ liệu này rất hiệu quả để tìm kiếm và tiếp thị đến các bà bầu. Khi bạn có bầu, bạn cần chuẩn bị cho em bé sắp sinh của mình bằng cách mua rất nhiều đồ. Target muốn khuyến khích các gia đình sắp đón em bé mua sắm ở cửa hàng của họ. Họ phân tích các dữ liệu khách hàng hiện tại để tìm ra cách nhận biết và tiếp cận những phụ nữ đang ở giai đoạn ba tháng giữa của thai kỳ.

Target có thể nhận thấy những thay đổi trong việc mua 25 sản phẩm cơ bản, bao gồm chất dinh dưỡng bổ sung, bông gòn, dưỡng thể không mùi, qua đó dự đoán một cách chính xác không chỉ việc khách hàng nào có thai mà còn biết cả ngày mà họ lâm bồn nữa. Nhờ đó, họ có thể gửi cho các bà bầu những phiếu mua hàng (coupon) phù hợp – được ngụy trang một cách có chủ ý trong số những phiếu chào hàng các sản phẩm phổ biến khác để họ không nhận ra mình đang là mục tiêu của cửa hàng – để khuyến khích họ mua sắm tại Target trước khi sinh em bé.

Dữ liệu lớn là một công cụ chứ không phải là giải pháp. Quan trọng là nó không thể thay thế sự thấu hiểu. Chúng ta vẫn cần có trực giác và cần đổi mới để cải thiện tiến trình xác định vấn đề và nhận định về nhu cầu và các vấn đề của khách hàng và người dùng, từ đó hình thành những giả thiết có thể đem ra kiểm thử và tìm kiếm thông tin. Các nhóm liên chức năng, các chân dung khách hàng và các cuộc phỏng vấn người dùng đều là những công cụ đắc lực giúp chúng ta thiết kế các thử nghiệm một cách hiệu quả và nhanh chóng hơn. Chúng ta cần học cách lắng nghe và hiểu biết từ dữ liệu thông qua các phân tích khách quan – nếu không thì dữ liệu của chúng ta chỉ là vô dụng: “Dữ liệu, giống như một ngọn đèn, chỉ hữu dụng khi người ta giơ nó lên soi và hiểu được những gì mà nó soi sáng.”

Sử dụng hiểu biết để đưa ra các giả thiết và thử nghiệm

Trong giai đoạn Khám phá, nhiều thành viên của nhóm liên chức năng sẽ có – và nên được khuyến khích chia sẻ – những hiểu biết thú vị và có giá trị về tổ chức, khách hàng, doanh nghiệp, các kênh phân phối hoặc các thị trường. Bằng cách chia sẻ những hiểu biết này trong nhóm, chúng ta có thể hình thành những quan điểm mới và tạo nguồn cảm hứng cho các sản phẩm và giải pháp mới.

Hãy đề nghị những người tham gia tiến trình Khám phá chia sẻ bất kỳ hiểu biết và dữ liệu thú vị nào mà họ có để thông báo, tạo ra hoặc thách thức các bản mô tả vấn đề bằng cách sử dụng khung trong Hình 4-4. Ví dụ:

Khách hàng

Nhóm đã có những thông tin cụ thể nào về các khách hàng hiện tại? Thái độ sử dụng và mức độ tham gia của họ là gì? Những hiểu biết đó giúp hình thành các cơ hội tương lai như thế nào cho những sản phẩm chào hàng hiện nay?

Các xu hướng thị trường

Xu hướng thị trường của ngành mà chúng ta đang cố gắng bước vào là chìa khóa để hiểu được các cơ hội tồn tại như thế nào và ở đâu – ví dụ như công nghệ di động, các dịch vụ định vị, thanh toán di động. Các xu hướng thị trường đối với các sản phẩm mà chúng ta đang sáng tạo là gì? Làm sao chúng ta có thể đánh giá đúng về chúng?

Hình 4-4. Khung Mô tả Vấn đề

Tổ chức

Nhóm đó có những thông tin cụ thể gì về tổ chức của chúng ta? Tổ chức của chúng ta tập trung nỗ lực của mình vào đâu? Tác động của những nỗ lực đó là gì? Tổ chức của chúng ta đảm trách được bao nhiêu phần trong bức tranh cạnh tranh lớn hơn? Và chúng ta thể hiện hiệu quả nhất ở điểm nào?

Bạn sẽ không tin đâu!

Mỗi công ty đều có những cá nhân sẵn sàng chia sẻ các thông tin thú vị và cập nhật về những giao dịch hoặc cơ sở khách hàng của họ. Làm thế nào để chúng ta có thể thử xem họ nói có đúng không và/hoặc từ đó có thể đem đến cơ hội hình thành những đánh giá mới về giá trị hay không?

Bằng cách làm rõ những thông tin này và thảo luận về nó, chúng ta có thể nỗ lực nhận dạng các mô hình kinh doanh mới và các tuyên bố giá trị phù hợp với doanh nghiệp trên cơ sở xem xét những khó khăn hiện nay và những bản mô tả vấn đề đã xác định.

GIA TĂNG THỬ NGHIỆM BẰNG MVP

Phong trào Doanh nghiệp Khởi nghiệp Tinh gọn thách thức giả định rằng khách hàng phải thấy được tất cả những đặc tính mà họ có thể tưởng tượng ra trong một sản phẩm trước khi bắt đầu sử dụng chúng. Eric Ries đưa ra thuật ngữ sản phẩm khả thi tối thiểu (MVP) để mô tả chiến lược đầu tư một lượng nguồn lực tối thiểu nhằm kiểm thử những giả định ưu tiên trong số các giả thiết của chúng ta về khách hàng. Mục tiêu là loại bỏ sự lãng phí bằng cách kiểm thử một giải pháp với các khách hàng đầu tiên càng sớm càng tốt.

Một MVP cho phép chúng ta sử dụng lượng nỗ lực tối thiểu để nhận được lượng hiểu biết tối đa khi thử nghiệm với khách hàng. Mục đích của việc sử dụng một MVP là thực hiện một thử nghiệm nhằm kiểm thử những giả định trong giả thiết của chúng ta càng rẻ, nhanh và hiệu quả thì càng tốt, để tìm hiểu xem giải pháp của chúng ta có giải quyết được vấn đề của khách hàng mà chúng ta đã xác định hay không. Điều đó giúp loại bỏ những phần của giả thiết vốn tạo ra sự phức tạp không cần thiết và tiêu hao một cách phí phạm các nguồn lực khi đem ra thử nghiệm với những khách hàng mục tiêu đầu tiên. Kết quả của thử nghiệm phải là sự hiểu biết để giúp chúng ta có thể đưa ra một quyết định dựa trên bằng chứng rõ ràng, từ đó chúng ta hoặc là kiên trì với mô hình kinh doanh hiện tại, hoặc chuyển hướng tìm phương pháp mới để đạt được mục tiêu, hoặc là dừng lại.

Điều quan trọng là phải phân biệt giữa một MVP theo quan điểm của Eric Ries với việc ra mắt sản phẩm vốn đang có xu hướng giống dạng thức kiểm thử beta với công chúng (Hình 4-5).

Hình 4-5. Sản phẩm khả thi tối thiểu: Xem cắt lớp thay vì xem từng lớp một

Điều rắc rối là mọi người thường quy bất kỳ hoạt động thẩm định nào ở bất kỳ đâu trong phổ trên đều là một MVP, làm sai lệch ý nghĩa của thuật ngữ này cũng như nhận thức về nó trong tổ chức hoặc trong ngành công nghiệp lớn hơn. Đáng chú ý, Marty Cagan, tác giả cuốn Inspired: How to Create Products Customers Love (tạm dịch: Truyền cảm hứng: Cách tạo ra những sản phẩm được khách hàng yêu thích) và cựu Phó Chủ tịch Cao cấp của eBay, đã sử dụng thuật ngữ “kiểm thử MVP” cho những gì mà Eric Ries gọi là một MVP. Cagan định nghĩa một MVP là “sản phẩm khả dĩ nhỏ nhất có ba đặc điểm quan trọng sau: Mọi người chọn sử dụng nó hoặc mua nó; mọi người có thể tìm ra cách sử dụng nó; và chúng ta có sẵn nguồn lực để phân phối nó khi cần – tức là có giá trị, dùng được và khả thi”. Còn chúng tôi thì đưa thêm từ “tạo ra sự say mê” bởi vì thiết kế và thẩm mỹ cũng rất quan trọng đối với một MVP cũng như với một sản phẩm hoàn chỉnh, như được thể hiện trong Hình 4-5. Hãy chắc chắn rằng nhóm của bạn và những người liên quan hiểu rõ MVP.

CÂU HỎI NÊN LÀ CHÚNG TA CÓ NÊN TẠO RA NÓ KHÔNG? CHỨ KHÔNG PHẢI CHÚNG TA CÓ THỂ TẠO RA NÓ KHÔNG?

JustGiving là một nền tảng quyên góp trực tuyến đã thu được hơn 2 tỷ bảng cho các hội từ thiện. JustGiving muốn khám phá những mô hình kinh doanh mới để tài trợ cho các sáng kiến cộng đồng mà không nhất thiết phải gắn với một hội từ thiện.

Họ thành lập một nhóm nhỏ các nhân viên tại cùng một bộ phận để nhanh chóng thử nghiệm với khách hàng. Họ tiến hành các cuộc họp về một phiên bản mẫu của nền tảng gây quỹ cộng đồng (crowdfunding) và kết thúc với việc đưa ra các dự án cộng đồng thực sự đồng thời tìm kiếm sự hỗ trợ. Dựa trên phản ứng tích cực từ khách hàng, họ tiếp tục xây dựng một MVP chăm sóc khách hàng, phát động các dự án cộng đồng ủy thác tương tự với các khách hàng thực trong khi kiểm soát thủ công các nhiệm vụ hậu cần như xây dựng dự án, xử lý giao dịch và thu tiền để đánh giá xem sản phẩm sẽ thể hiện trên thị trường như thế nào.

Trong vòng 7 tuần từ khi bắt đầu sáng kiến, JustGiving đã thẩm định được một mô hình kinh doanh có khả năng tái lặp và có quyền bắt đầu áp dụng thực tế vào một doanh nghiệp. Sản phẩm này hiện nay chính là YIMBY với những câu chuyện thành công bao gồm việc mua xe lăn chơi bóng rổ cho các đội, mua dụng cụ để mở rộng một khu vườn cộng đồng và giải cứu Câu lạc bộ Bóng đá có tuổi đời 140 năm của thành phố Kettering.

Những MVP, như được thể hiện trong Bảng 4-2, không đảm bảo cho thành công; chúng được thiết kế để kiểm thử những giả định của một vấn đề chúng ta mong muốn giải quyết mà không phải đầu tư quá mức. Cho đến nay, kết quả chắc chắn nhất là chúng ta biết được những giả định của mình là vô hiệu và vì vậy cần phải chuyển hướng hoặc ngừng cách tiếp cận đó. Mục đích cuối cùng của chúng ta là giảm thiểu đầu tư trong quá trình tìm kiếm các giải pháp cho đến khi chúng ta tự tin là đã khám phá ra sản phẩm đúng – sau đó khai thác cơ hội này bằng cách gia tăng tính phức tạp và giá trị để tạo ra sản phẩm đúng.

Bảng 4-2. Ví dụ về các loại MVP

Làm thế nào để thống nhất tầm nhìn của chúng ta và MVP?

Cagan nhấn mạnh rằng tầm nhìn và MVP gắn bó chặt chẽ nhưng không phải là một. Cagan định nghĩa tầm nhìn là hiểu biết chung về “loại dịch vụ mà bạn định cung cấp và đối tượng khách hàng mà bạn định phục vụ, thông thường trong khung thời gian từ 2-5 năm.” Như vậy, tầm nhìn cung cấp một lộ trình và bối cảnh cho các MVP và chúng ta cần sẵn sàng tạo ra nhiều MVP trong quá trình tìm kiếm một tiến trình phát triển khách hàng tái lặp, có khả năng tăng trưởng và gắn với tầm nhìn của chúng ta.

Những nhà phát triển ý tưởng đầu tiên, đặc biệt là trong các doanh nghiệp, cần nắm vững toàn bộ tầm nhìn, chứ không chỉ là thử nghiệm MVP đầu tiên. Họ sẽ cần nghe về những gì mà tổ chức của chúng ta dự định đạt được trong 6-18 tuần tới. Họ tiếp nhận tầm nhìn về những gì mà chúng ta đang cố gắng giành lấy và có thể bù đắp những thiếu hụt trong giải pháp của chúng ta vì họ cảm nhận được những thách thức của vấn đề mà chúng ta đang cố gắng giải quyết. Bằng cách cho họ hiểu được giải pháp mà chúng ta đang định xây dựng, chúng ta đã cho họ bằng chứng rằng giải pháp đó có ích và cung cấp cơ hội phản hồi về giải pháp mà chúng ta đang xây dựng.

Đẩy mạnh tương tác và sự tham gia trong doanh nghiệp là điều rất quan trọng trong những giai đoạn đầu của một sáng kiến mới. Phản hồi và bằng chứng giành được nhờ sử dụng một MVP cung cấp hiểu biết sâu hơn và giúp hiểu thái độ của khách hàng hơn là các biện pháp tổng thể như tổng doanh thu hay tổng giá trị giao dịch. MVP cho phép chúng ta tập trung vào việc tạo ra điều đúng đắn và cung cấp thông tin có giá trị về cách thức phát triển, thích nghi và điều chỉnh nhằm đáp ứng nhu cầu của khách hàng được khám phá ra trong quá trình thử nghiệm, như được thể hiện trong Hình 4-6.

Hình 4-6. Chu trình định hình và thử nghiệm đánh giá MVP

Bắt đầu bằng câu hỏi chúng ta muốn biết điều gì từ cuộc thử nghiệm đó, chúng ta có thể xác định cách quan sát và đánh giá cuộc thử nghiệm và cuối cùng tạo ra một MVP rẻ nhất, nhanh nhất và đơn giản nhất để kiểm thử những giả định của mình, đánh giá tác động và sử dụng hiểu biết đó để xác định các bước tiếp theo.

Một điểm căn bản ở các sáng kiến mới là duy trì dòng tiền và nhanh chóng làm lại trong khi các nhóm đang kiểm thử các giả thiết để xác định một giải pháp có khả năng lặp lại. Một khi chúng ta đã hiểu những điểm căn bản đó và đạt được một sản phẩm phù hợp với thị trường, thì việc duy trì dòng tiền trở nên ít quan trọng hơn việc sử dụng nó và chúng ta có thể bắt đầu tạo ra một giải pháp có khả năng mở rộng.

Thông số quan trọng nhất

Khi thiết kế các MVP để thử nghiệm, điều quan trọng là phải xác định một thông số then chốt có thể giúp chúng ta hiểu được liệu các giả định trong giả thiết của chúng ta có đúng hay không. Các tác giả Alistair Croll và Benjamin Yoskovitz của cuốn Lean Analytics (Phân tích dữ liệu tinh gọn⁸) giới thiệu khái niệm Thông số quan trọng nhất (One Metric That Matters - OMTM). OMTM là một thông số mà chúng ta ưu tiên và coi là điều quan trọng nhất để đưa ra quyết định dựa trên giai đoạn của vòng đời sản phẩm và mô hình kinh doanh của mình. Đó không phải là một đơn vị đo lường đơn lẻ mà chúng ta sẽ sử dụng trong suốt vòng đời sản phẩm mà sẽ thay đổi theo thời gian tùy thuộc vào phạm vi vấn đề mà chúng ta muốn giải quyết.

⁸ Được Alpha Books mua bản quyền và xuất bản năm 2018.

Chúng ta tập trung vào Thông số quan trọng nhất để:

◆ Trả lời cho câu hỏi khó nhất của mình bằng cách gắn nó với những giả định trong các giả thiết mà chúng ta muốn kiểm thử

◆ Xác định trọng tâm, trao đổi và suy nghĩ để xác định các vấn đề khó khăn và khuyến khích đổi mới

◆ Cung cấp sự minh bạch và hiểu biết chung trong toàn nhóm và trong tổ chức lớn hơn

◆ Hỗ trợ văn hóa thử nghiệm bằng cách dựa vào các tỷ lệ hay tỷ số, chứ không phải mức trung bình hay tổng số, phù hợp với hệ dữ liệu lịch sử của chúng ta

Thông số này không phải là một thông số lạc hậu như tỷ suất hoàn vốn (ROI) hay tỷ lệ khách hàng rời bỏ (customer churn) – hai khái niệm dùng để đo lường kết quả sau khi sự việc đã xảy ra. Các dấu hiệu lạc hậu sẽ trở nên thú vị khi chúng ta đạt được sự hòa hợp giữa sản phẩm và thị trường. Bằng cách dành nỗ lực ban đầu cho các thông số quan trọng nhất, chúng ta có thể nhận ra dấu hiệu của điều chắc chắn sẽ xảy ra – và giải quyết một tình huống nhanh hơn để kiểm thử và thay đổi kết quả sắp xảy đến. Ví dụ, những than phiền của khách hàng thường là dấu hiệu nổi bật nhất của việc một số khách hàng sẽ rời đi. Nếu những than phiền đó gia tăng thì ta có thể dự đoán rằng khách hàng sẽ rời đi với số lượng lớn hơn. OMTM của chúng ta luôn phải tăng lên khi chúng ta hiểu thêm về vấn đề mà mình muốn giải quyết.

Mục đích của OMTM là thu được bằng chứng khách quan về việc những thay đổi mà chúng ta đang tạo ra với sản phẩm của mình có tác động đến thái độ của khách hàng theo cách có thể đo lường được. Cuối cùng thì chúng ta phải hiểu:

◆ Chúng ta có đang tiến bộ không? (Điều gì)?

◆ Điều gì gây ra sự thay đổi đó (Tại sao)?

◆ Chúng ta cải tiến bằng cách nào (Như thế nào)?

Nhà sáng lập Intuit, Scott Cook, cho rằng các nhà sáng lập nên tập trung vào “các thông số yêu thương” (love metrics). Ví dụ, có bao nhiêu người yêu thích sản phẩm đó, họ trở lại với sản phẩm đó thường xuyên như thế nào, hoặc họ cảm thấy vui lòng như thế nào trong những giai đoạn đầu. “Nếu bạn không nhận được những tín hiệu từ người dùng mà bạn có, thì đã đến lúc bạn phải chuyển hướng.” Việc chọn OMTM sẽ giúp tạo ra sự minh bạch, sự gắn kết và tập trung cho các nhóm, vì vậy giúp đưa ra những quyết định hiệu quả, đặc biệt đối với những sáng kiến ở giai đoạn đầu.

BÍ QUYẾT

Sử dụng Tư duy A3 làm phương pháp hệ thống để nhận diện những cơ hội cải tiến

Tư duy A3 là một công cụ giải quyết vấn đề một cách lô-gic nhằm thu thập thông tin và xác định trọng tâm và sức ép của nhóm. Sau đó, nó trở thành một biện pháp để kiểm thử các kết quả của chúng ta. Một bản báo cáo A3 (gọi như vậy là vì nó phù hợp với việc trình bày trên một tờ giấy cỡ A3) bao gồm bảy thành tố, thể hiện cho chu trình thử nghiệm Lập kế hoạch-Thực thi-Kiểm tra-Hành động:

Nền tảng

Thu thập những thông tin trọng yếu để hiểu phạm vi và tầm quan trọng của vấn đề. Việc gắn nền tảng đó với tuyên bố mục đích sẽ làm giảm sự lãng phí nhờ hạn chế được khả năng dành sự tập trung vào sai chỗ.

Điều kiện hiện tại và bản mô tả vấn đề

Đây là vấn đề mà nhà doanh nghiệp muốn trình bày, bằng những thuật ngữ đơn giản và dễ hiểu chứ không phải là một tuyên bố không thể hiện được giải pháp. Ví dụ, hãy tránh những tuyên bố kiểu như “Vấn đề của chúng ta là chúng ta cần một Hệ thống Quản lý Nội dung.”

Tuyên bố mục đích

Làm thế nào để chúng ta biết rằng các nỗ lực của mình đã thành công sau khi kết thúc giai đoạn thực hiện? Sẽ lý tưởng nếu chúng ta có một thông số then chốt để đánh giá thành công. Ví dụ, “Mục đích của chúng ta là giảm sai lầm của hệ thống so với kết quả kiểm thử 22 vấn đề chính trước đây; mục tiêu của chúng ta là giảm xuống còn 20%.”

Phân tích nguyên nhân gốc rễ của vấn đề

Trình bày tỉ mỉ giả thiết và các giả định hoặc một tập hợp các thử nghiệm được thực hiện để kiểm thử, tìm nguyên nhân và kết quả.

Biện pháp đối phó

Thống kê danh sách những bước thử nghiệm cần phải thực hiện để kiểm thử giả thiết đó.

Kiểm tra/khẳng định hiệu quả

Xác định một phương pháp để đánh giá xem liệu các biện pháp đối phó có hiệu quả hay không.

Các hành động tiếp theo và báo cáo

Xác định các bước tiếp theo và chia sẻ những gì bạn tìm hiểu được với nhóm và với tổ chức.

Để biết thêm về Tư duy A3, hãy đọc cuốn Understanding A3 Thinking: A Critical Component of Toyotas PDCA Management System (tạm dịch: Hiểu tư duy A3: Một thành tố quan trọng trong hệ thống quản lý PDCA⁹ của các tác giả Durward K. Sobek II và Art Smalley. Những ví dụ khác bao gồm “Nghệ thuật rao thang máy”¹⁰ và nhóm “5W và 1H” (Who, What, Where, When, Why và How) (tạm dịch: Ai, Cái gì, Ở đâu, Khi nào, Tại sao, Như thế nào).

⁹ Chu trình Lập kế hoạch – Thực hiện – Kiểm tra – Điều chỉnh của Toyota. (ND)

¹⁰ Elevator pitch: Là một thuật ngữ trong ngành tiếp thị dùng để chỉ phương pháp giới thiệu về bản thân, doanh nghiệp, sản phẩm, dịch vụ hoặc giải pháp một cách ngắn gọn nhưng thuyết phục. (BTV)

Hãy nhớ rằng các thông số sẽ gây đau đầu chứ không khiến chúng ta thích thú như khi đang giành được chiến thắng. Chúng phải có khả năng hành động và thúc đẩy sự thay đổi trong thái độ hoặc hiểu biết của chúng ta. Chúng ta cần xem xét hai câu hỏi then chốt này khi quyết định OMTM của chúng ta là gì:

Vấn đề mà chúng ta đang cố gắng giải quyết là gì?

Phát triển sản phẩm

Có đúng là chúng ta đang cố gắng tạo ra các sản phẩm hoặc dịch vụ mới liên quan tới khách hàng không? Làm thế nào để biết rằng chúng ta đang thu hút họ và họ quan tâm đến sản phẩm của chúng ta?

Lựa chọn công cụ

Chúng ta đang cố gắng lựa chọn một công cụ để sử dụng trong tổ chức? Làm thế nào để biết đó sẽ là công cụ tốt nhất cho tiến trình?

Cải thiện tiến trình

Có phải chúng ta đang cố gắng cải thiện nội lực và hiệu quả của mình? Làm thế nào để biết liệu những thay đổi của chúng ta có đem lại hiệu quả mong muốn hay không?

Chúng ta đang ở giai đoạn nào của tiến trình?

Thẩm định vấn đề

Chúng ta đang cố gắng xác định rằng có vấn đề nào tồn tại hay không bằng cách trò chuyện với mọi người để xem liệu họ có đang trải qua tác động của vấn đề mà chúng ta đang giải quyết hay không?

Thẩm định giải pháp

Người của chúng ta có thể hiện sự gắn kết và có nhận thức được vấn đề mà chúng ta đang tìm cách giải quyết thông qua các cuộc phỏng vấn định tính hay không?

Thẩm định MVP

Chúng ta có tạo được những thử nghiệm để chứng minh một cách định lượng rằng giải pháp của mình có hiệu quả trong giải quyết vấn đề đã xác định không?

OMTM là một công cụ hữu dụng để đơn giản hóa tính phức tạp của các phân tích. Đặc biệt, nó cho chúng ta biết liệu giải pháp của mình có đang thành công hay không. Một khi xác định được thông số then chốt đó để tập trung các nỗ lực vào đó, chúng ta sẽ xác định được những thông số hỗ trợ giúp hiểu biết thêm về những lĩnh vực khác và hỗ trợ tiến trình ra quyết định.

Một ví dụ hay về OMTM là tại LinkedIn, nhóm không nói về “tổng số lượt xem trang” mà chỉ quan tâm đến “lượt xem hồ sơ” – số lượng người dùng LinkedIn để tìm kiếm và phát hiện những người khác, và số lượng những hồ sơ LinkedIn mà họ xem.

KẾT LUẬN

Giai đoạn Khám phá cho phép chúng ta tìm kiếm cơ hội trong điều kiện vô cùng bất trắc – đặc biệt là trong phát triển sản phẩm mới và đổi mới mô hình kinh doanh. Các khái niệm và công cụ khám phá cho phép chúng ta đầu tư nỗ lực nhỏ nhất để giành được số lượng tối đa hiểu biết nhằm tạo ra những tiến bộ có thể đo lường được và hướng đến việc khai thác các cơ hội đã được thẩm định. Khám phá tạo ra một tầm nhìn rõ ràng và hiểu biết chung về vấn đề mà chúng ta đang cố gắng giải quyết trong tổ chức của mình.

Chúng ta phải chấp nhận rằng tất cả các ý tưởng của mình đều là giả thiết dựa trên những giả định cần phải được kiểm thử, và rằng phần lớn những giả định này sẽ được chứng minh là sai. Bằng cách ra quyết định dựa trên những thông tin thu thập từ những thử nghiệm MVP được thực hiện một cách nhanh và rẻ, chúng ta có thể đưa ra các quyết định đầu tư tốt hơn. Càng sớm chuyển hướng hoặc chấm dứt các ý tưởng tồi, chúng ta càng đỡ tốn thời gian, nguồn lực và càng có thể dồn tâm huyết cho những ý tưởng sẽ đem lại giá trị cho khách hàng hoặc hình thành các ý tưởng mới.

Câu hỏi dành cho độc giả:

◆ Giả thiết kinh doanh hiện nay của bạn là gì và bạn làm thế nào để tạo ra một thử nghiệm sử dụng một MVP để kiểm thử nó?

◆ Bạn có đặt câu hỏi “chúng ta có nên xây dựng nó” trước khi theo đuổi câu trả lời về việc “chúng ta có thể xây dựng nó” hay không?

◆ Nhóm của bạn sẽ thực hiện những thử nghiệm nào và họ sẽ thu thập những bằng chứng nào để quyết định thời điểm chuyển hướng, tiếp tục hay dừng lại?

◆ Thông số chính của bạn là gì?

Chương 5Đánh giá sự hòa hợp giữa sản phẩm/thị trường

Giới hạn cuộc sống... không có cách nào để giải thích về nó bởi vì những người duy nhất thực sự biết nó ở đâu là những người đã từng trải qua nó.

− HUNTER S. THOMPSON

Trong chương này, chúng tôi sẽ thảo luận cách xác định thời điểm đạt được một sản phẩm phù hợp với thị trường và cách thoát khỏi giai đoạn Khám phá để bắt đầu khai thác sản phẩm của mình với thị trường đã xác định. Chúng tôi sẽ trình bày cách sử dụng các thông số tùy biến để hiểu liệu chúng ta có đạt được những kết quả kinh doanh đáng kể trong khi tiếp tục giải quyết các vấn đề của khách hàng bằng cách thu hút họ trong suốt tiến trình phát triển hay không.

Chúng tôi sẽ nghiên cứu cách mà các tổ chức vươn tới thành công với chiến lược, cấu trúc và sự hỗ trợ đúng mức, cùng với cách mà họ tìm kiếm những khách hàng trong và ngoài nước để thu thập những phản hồi và hiểu biết có giá trị khi họ phát triển sản phẩm của mình. Chúng tôi sẽ nghiên cứu cách thúc đẩy những năng lực, dịch vụ và biện pháp hiện có để đánh giá sản phẩm của mình trong khi tìm cách thúc đẩy sự phối hợp làm việc trong tổ chức. Cuối cùng, chúng tôi sẽ mô tả các thông số và động lực của sự tăng trưởng giúp quản lý quá trình chuyển đổi giữa các đường chân trời thể hiện mô hình kinh doanh khi chúng ta bắt đầu đánh giá giải pháp của mình.

KẾ TOÁN ĐỔI MỚI

Chỉ nỗ lực hết mình thôi là chưa đủ; bạn phải biết sẽ làm gì đã, sau đó mới làm hết sức mình.

− W. EDWARDS DEMING

Chúng ta sống trong một thế giới quá tải về thông tin, nơi mà bất kỳ lập luận nào cũng đều có thể tìm thấy các dữ liệu chứng minh xem chúng ta có thẩm định cẩn thận các giả định của mình hay không. Tìm kiếm thông tin để chứng minh cho một triết lý không bao giờ là vấn đề cả, nhưng kiểm thử triết lý đó và hành động đúng mới là điều khó khăn.

Như được thảo luận trong Chương 3, rủi ro lớn thứ hai cho bất kỳ sản phẩm mới nào là đầu tư nỗ lực vào những sai lầm. Vì vậy, điều cấp thiết là chúng ta không đầu tư quá mức vào những cơ hội chưa được chứng minh bằng cách làm điều sai theo cách đúng. Chúng ta phải bắt đầu một cách tự tin rằng chúng ta thực sự đang làm điều đúng. Làm thế nào mà chúng ta kiểm thử được rằng trực giác của chúng ta là đúng, đặc biệt là khi hoạt động trong những điều kiện cực kỳ bất trắc?

Eric Ries giới thiệu thuật ngữ kế toán đổi mới để nói đến tiến trình thực hiện nghiêm ngặt việc xác định, thử nghiệm, đo lường và thông tin về những tiến bộ thực sự trong đổi mới sản phẩm, mô hình kinh doanh hoặc các sáng kiến. Để hiểu liệu sản phẩm của mình có giá trị và được khách hàng tin cậy hay không, chúng ta tập trung thu thập các bằng chứng được chấp nhận và vạch ra một quỹ đạo hợp lý trong khi vẫn khám phá những lĩnh vực mới.

Các tiêu chuẩn kế toán tài chính truyền thống như năng lực vận hành, dòng tiền mặt hoặc tỷ lệ các chỉ số lợi nhuận như tỷ suất hoàn vốn (ROI) – những thứ không được thiết kế để đổi mới – thường tác động theo hướng làm khó hoặc phá hủy những sản phẩm hay sáng kiến mới. Chúng có tác dụng tối ưu và hiệu quả hơn khi khai thác những lĩnh vực đã được hiểu rõ hoặc các mô hình kinh doanh và sản phẩm đã có sẵn. Theo định nghĩa, những cải cách mới có lịch sử hoạt động hạn chế, ít hoặc hoàn toàn không có doanh thu và đòi hỏi phải được đầu tư để bắt đầu, như được thể hiện trong Hình 5-1. Trong bối cảnh đó, tỷ suất hoàn vốn, các phân tích tỷ lệ tài chính, các phân tích dòng tiền mặt và các tiêu chuẩn tương tự cung cấp rất ít hiểu biết về giá trị của một sáng kiến cải cách mới cũng như không giúp đánh giá kết quả đầu tư so với hiệu năng của các sản phẩm đã có nếu chỉ thông qua việc so sách các dữ liệu tài chính đơn thuần.

Hình 5-1. Tỷ lệ lợi nhuận trên doanh số của các sáng kiến trong giai đoạn đầu

Trong giai đoạn Khám phá, không được bỏ qua hay coi thường công tác kế toán. Đơn giản là cần có cách hiểu khác về đánh giá kết quả của việc đổi mới và những sáng kiến trong giai đoạn đầu. Các nguyên tắc kế toán và đánh giá đổi mới của chúng ta phải giải quyết được các mục tiêu sau:

◆ Tạo dựng tín nhiệm cho các quyết định và tiêu chí đánh giá.

◆ Quản lý rủi ro đi kèm với sự không chắc chắn.

◆ Báo hiệu về những cơ hội và sai lầm nảy sinh.

◆ Cung cấp thông tin chính xác về các phân tích đầu tư và quản lý rủi ro.

◆ Chấp nhận rằng đôi khi chúng ta sẽ cần phải xúc tiến công việc mà không có đầy đủ thông tin.

◆ Xác định được cách thức để không ngừng cải thiện khả năng đổi mới của tổ chức.

CẢNH BÁO

Những sai lầm trong đánh giá

“Bạn đánh giá điều gì thì sẽ nhận được điều đó.”

– KAPLAN & NOTON

Một trong những ý tưởng chủ chốt của Eric Ries trong cuốn Khởi nghiệp tinh gọn là sử dụng những thông số hành động. Ông chủ trương cần đầu tư năng lượng vào việc thu thập những thông số giúp chúng ta đưa ra quyết định. Điều không may là thông thường những gì được thu thập và xã hội hóa trong các tổ chức mà chúng ta dễ nhận thấy lại là những thông số ảo vốn cho chúng ta cảm giác vui vẻ nhưng không giúp định hướng rõ ràng về hành động cần thực hiện.

Trong cuốn Phân tích dữ liệu tinh gọn, Alistair Croll và Benjamin Yoskovitz lưu ý: “Nếu bạn có dữ liệu về điều mà bạn không thể thực hiện, đó là một thông số ảo... Một thông số tốt sẽ làm thay đổi cách ứng xử của bạn. Cho đến nay, đây là tiêu chuẩn quan trọng nhất đối với một thông số: bạn sẽ làm gì khác dựa trên những thay đổi của thông số đó?” Một vài ví dụ về thông số ảo và thông số hành động tương ứng được thể hiện trong Bảng 5-1.

Bảng 5-1. Ví dụ về các thông số ảo và thông số hành động

Trong cuốn How to measure anything, Douglas Hubbard giới thiệu một kỹ thuật hay để ra quyết định trên cơ sở một tiêu chuẩn có sẵn: “Nếu bạn có thể xác định chính xác kết quả mà bạn thực sự mong muốn, hãy đưa ra các ví dụ và tìm cách quan sát những hệ quả của chúng, sau đó bạn có thể hình thành những phương pháp đánh giá giúp tìm hiểu về những hệ quả quan trọng. Vấn đề ở đây là, nếu có điều gì xảy ra, các nhà quản lý có xu hướng chỉ đánh giá những gì đơn giản nhất (ví dụ như những gì họ đã biết cách đánh giá), chứ không phải là những gì quan trọng nhất.”

Bằng cách kết hợp nguyên tắc thông số hành động với đề xuất của Hubbard về cách xác định các tiêu chuẩn quan trọng nhất, chúng ta có thể bỏ qua năng suất nội bộ và các biện pháp tài chính truyền thống để tập trung vào giá trị quan trọng nhất đối với tầm nhìn của các bên liên quan – đó là khách hàng của chúng ta.

“Những thông số cướp biển (pirate metrics¹) của Dave McClure là một cách khéo léo để tạo hình bất kỳ doanh nghiệp định hướng dịch vụ nào, như được thể hiện trong Bảng 5-2 (chúng ta làm theo Ash Maurya khi đặt Doanh thu trước việc Giới thiệu cho khách hàng khác). Hãy lưu ý rằng để áp dụng các thông số cướp biển một cách hiệu quả, chúng ta phải luôn đánh giá chúng theo đoàn hệ. Một đoàn hệ là một nhóm người có những đặc điểm chung trong ngày đầu tiên họ sử dụng dịch vụ của bạn. Vì vậy khi trình bày những thông số hình phễu như của McClure, chúng ta lọc ra những kết quả không phải là một phần của đoàn hệ mà chúng ta quan tâm.

¹ Hình thành từ các “loại” thông số bao gồm Nhận thức (Awareness), Thu hút khách hàng (Acquisition), Kích hoạt tài khoản/khách hàng (Activation), Doanh thu (Revenue), Giữ chân khách hàng (Retention), Giới thiệu cho khách hàng khác (Referral), viết tắt là AAARRR – vì đọc lên giống như âm thanh cướp biển cầm thanh kiếm đe dọa. (ND)

Bảng 5-2. Các thông số cướp biển: AARRR!

Đánh giá những thông số cướp biển cho mỗi đoàn hệ sẽ cho phép bạn đánh giá tính hiệu quả của những thay đổi đối với sản phẩm hoặc mô hình kinh doanh của bạn nếu bạn đang chuyển hướng. Kích hoạt tài khoản/khách hàng và Giữ chân khách hàng là những thông số mà bạn quan tâm để đánh giá sự ăn khớp của vấn đề và giải pháp. Doanh thu, Giữ chân khách hàng và Giới thiệu cho khách hàng khác là những ví dụ của các thông số yêu thương – điều mà bạn quan tâm khi đánh giá một sản phẩm phù hợp với thị trường. Trong Bảng 5-3 chúng ta tái thể hiện tác động đến các thông số cướp biển của việc thay đổi mang tính cải tiến và chuyển hướng cho sản phẩm của Votizen. Hãy lưu ý rằng thứ tự và ý nghĩa của các thông số phần nào khác với Bảng 5-2. Điều quan trọng là bạn phải chọn được những thông số phù hợp với sản phẩm của mình (đặc biệt nếu đó không phải là một dịch vụ). Hãy luôn chú ý tới các thông số hành động!

Bảng 5-3. Tác động của việc thay đổi mang tính cải tiến và chuyển hướng sản phẩm đối với các thông số cướp biển của Votizen

Để xác định xem một sản phẩm có phù hợp với thị trường hay không, chúng ta cũng sẽ cần thu thập thêm các thông số kinh doanh khác như thể hiện trong Bảng 5-4. Lúc nào cũng vậy, điều quan trọng không phải là thu thập những thông số chính xác một cách không cần thiết. Nhiều trong số những thông số tăng trưởng này cần phải được đánh giá trên cơ sở đoàn hệ, ngay cả khi nó chỉ diễn ra trong một tuần.

Bảng 5-4. Đường chân trời của ba thông số tăng trưởng

Những thông số mà chúng ta quan tâm ở một thời điểm bất kỳ sẽ phụ thuộc vào bản chất mô hình kinh doanh của chúng ta và những giả định nào mà chúng ta đang cố gắng thẩm định. Chúng ta có thể kết hợp các thông số quan tâm vào một bảng điểm đánh giá (scorecard) như được thể hiện trong Hình 5-2.

Các thông số thành công khách hàng² (customer success metrics) giúp chúng ta nhận thức về việc liệu khách hàng có tin tưởng vào giá trị sản phẩm của chúng ta hay không. Trái lại, các thông số kinh doanh tập trung vào thành công của chính mô hình kinh doanh của chúng ta. Như chúng tôi đã lưu ý ở phần trước, thu thập dữ liệu không bao giờ là một vấn đề đối với một sáng kiến mới; những khó khăn nằm ở chỗ có nhận được những thông số hành động, có đạt được mức độ chính xác cần thiết và không bị lạc lối trong tất cả những ồn ào xung quanh hay không.

² Thành công khách hàng (customer success): Là hoạt động quản lý mối quan hệ giữa doanh nghiệp và khách hàng với mục đích giúp khách hàng thành công ở mức cao nhất có thể, từ đó giúp cải thiện giá trị vòng đời khách hàng cho doanh nghiệp. Đây là hoạt động ngày càng có tầm quan trọng hơn trong kinh doanh. (BTV)

Để giúp quá trình cải tiến, bảng thông số của chúng ta chỉ nên đề cập những thông số sẽ thúc đẩy sự thay đổi thái độ của khách hàng và thể hiện những mục tiêu cần cải thiện. Nếu chúng ta không khao khát hành động dựa trên những thông tin trên bảng đó, tức là chúng ta đang xem xét những điều sai lầm hoặc nghiên cứu không đủ sâu nên không nắm được những dữ liệu hành động ở mức độ phù hợp.

Hình 5-2. Ví dụ về bảng thông số cải tiến

Xét về mặt quản lý, điều quan trọng nhất cần làm là phải tiến hành họp thường xuyên hằng tuần hoặc hai tuần một lần giữa những người dẫn đầu về sản phẩm và kỹ thuật trong nhóm cùng với một vài bên liên quan chủ chốt ở ngoài nhóm (ví dụ như một lãnh đạo phụ trách Hồ sơ Đường chân trời 3 và sản phẩm cao cấp của nó cùng các đại diện kỹ thuật). Trong cuộc họp, chúng ta sẽ đánh giá trạng thái của các thông số được lựa chọn và cập nhật những thông số trọng tâm (bao gồm cả Thông số quan trọng nhất – OMTM). Mục đích của cuộc họp là để quyết định xem nhóm có nên tiếp tục kiên nhẫn hay nên chuyển hướng và cuối cùng quyết định xem liệu nhóm đã phát hiện ra một sản phẩm phù hợp với thị trường hay chưa hay thực sự cần làm lại và tập trung vào điều gì khác có giá trị hơn.

Các bên liên quan ngoài nhóm cần đặt ra những câu hỏi hóc búa để giúp cho nhóm nhận thức rõ về sự tiến bộ của mình.

KHUYẾN KHÍCH NGƯỜI ỦNG HỘ TRONG NỘI BỘ DOANH NGHIỆP

Việc đổi mới trong các tổ chức lớn và quan liêu là một thách thức vì họ vốn được thiết kế để hỗ trợ sự ổn định, sự tuân thủ và không ưu tiên tiếp nhận rủi ro. Các nhà lãnh đạo hàng đầu có thể làm vậy vì họ đã làm việc trong hệ thống đó như nó đang tồn tại đến nay. Vì vậy, chúng ta cần thận trọng để bất kỳ lời chỉ trích nào cũng không được tập trung vào các cá nhân hay hành vi của họ trong hệ thống. Chúng ta cần tìm ra các cộng tác viên và đồng sáng lập viên trong khắp tổ chức mà không gây ra sự ghét bỏ nhằm giành được sự ủng hộ lớn hơn cho các nỗ lực của mình và vượt qua sự cách biệt để đi đến giai đoạn chấp nhận đường cong tiếp theo trong nội bộ tổ chức. Cuối cùng, chúng ta sẽ cần xác định những yếu tố cần thay đổi để có được thành công. Lập luận tốt nhất ở đây là các bằng chứng biểu thị khẳng định rằng các nỗ lực của chúng ta đã đem lại những kết quả kinh doanh đáng kể.

Chắc chắn rằng trong tổ chức sẽ có những người đang tức giận và tò mò về sự thay đổi đó. Tuy nhiên, họ sẽ tìm kiếm sự an toàn, bình phong và vỏ bọc để hành động trước khi sẵn sàng chủ trương thúc đẩy một sáng kiến. Khuyến khích và lôi kéo những người này là chìa khóa của vấn đề. Khi trở thành những người đầu tiên chấp nhận các ý tưởng và sáng kiến của chúng ta, họ sẽ cung cấp vòng phản hồi giúp chúng ta tái lặp và cải thiện sản phẩm của mình. Họ cũng là những nhà tài trợ của chúng ta trong tổ chức lớn hơn. Trong môi trường quan liêu, mọi người có xu hướng bảo vệ thương hiệu cá nhân. Mục đích của chúng ta là trao cho họ sự tự tin, các nguồn lực và bằng chứng khuyến khích họ cống hiến cho sáng kiến của chúng ta trên toàn tổ chức.

LÀM NHỮNG VIỆC KHÔNG TĂNG TRƯỞNG

Ngay cả khi đã thẩm định những giả định rủi ro nhất về mô hình kinh doanh của mình, điều quan trọng là chúng ta phải tiếp tục tập trung vào các nguyên tắc về “sự đơn giản và thử nghiệm”. Chúng ta phải tiếp tục tối ưu hóa việc học hỏi và không rơi vào tình trạng chỉ đơn giản là cung cấp các tính năng. Sự nỗ lực, một khi đã có được đà, phải tập trung vào việc tìm cách tự động hóa, thực thi và cân nhắc tất cả những gì được coi là “yêu cầu” để phát triển giải pháp của chúng ta. Tuy nhiên, đây không nên là trọng tâm.

Trong những giai đoạn đầu, chúng ta nên bớt thời gian lo lắng cho sự phát triển để tập trung tương tác với những khách hàng quan trọng. Có thể chỉ thu hút từng cá nhân khách hàng bởi quá nhiều khách hàng ngay từ đầu có thể dẫn tới việc thiếu tập trung và làm giảm tốc độ. Chúng ta cần tập trung tìm kiếm những người tiếp nhận nhiệt tình đầu tiên để tiếp tục thử nghiệm và học hỏi. Sau đó, chúng ta tìm cách can dự với phân khúc khách hàng tương tự cuối cùng “vượt qua sự cách biệt”, từ đó thu hút được nhiều khách hàng hơn.

Điều này sẽ là bất thường đối với đa số các sáng kiến trong các tổ chức. Chúng ta được lập trình để đạt sự tăng trưởng bùng nổ, vì vậy, thực hiện những việc không đem lại sự tăng trưởng không phù hợp với những gì mà chúng ta được huấn luyện để làm. Tương tự như vậy, chúng ta có xu hướng đánh giá mức độ cần thiết của dịch vụ, chi tiêu và thành công trong mối tương quan với doanh thu, kích cỡ và quy mô của nhiều sản phẩm chín muồi³ trong môi trường hoặc lĩnh vực cạnh tranh của chúng ta.

³ Sản phẩm chín muồi (mature product): Chỉ sản phẩm đã đạt tới giai đoạn phát triển chín muồi trong vòng đời của mình. (BTV)

Chúng ta phải nhớ rằng mình vẫn đang ở trong giai đoạn hình thành của tiến trình khám phá, và không muốn đầu tư quá nhiều hay cam kết đạt đến một giải pháp quá sớm. Trong hành trình của mình, chúng ta liên tục kiểm thử và thẩm định những giả định từ mô hình kinh doanh của mình qua những thử nghiệm thị trường. Nếu đã xác định được một khách hàng chủ chốt với một vấn đề và có thể hành động để thỏa mãn vấn đề đó, chúng ta đã có một cơ hội khả thi để tạo ra một điều mà nhiều người muốn. Để bắt đầu, chúng ta không cần liên đới mọi bộ phận, mọi phân khúc khách hàng hoặc mọi thị trường. Chúng ta chỉ cần đồng sáng tạo với một khách hàng trọng tâm.

Một khi các nhà lãnh đạo nhận thấy bằng chứng về khả năng tăng trưởng vượt bậc khi chúng ta thực hiện những tiến trình không tăng trưởng, chúng ta sẽ dễ dàng nhận được sự đảm bảo về nhân lực, ngân sách và sự ủng hộ để hình thành các giải pháp kiểm soát dòng cầu tuyệt vời. Mục đích của chúng ta nên là tạo ra một hệ thống kéo (pull) để thu hút khách hàng mong muốn sản phẩm, dịch vụ hoặc công cụ của chúng ta, chứ không phải đẩy (push) ra một giải pháp được nghiền ngẫm, lên kế hoạch và ủy quyền cho những người mà chúng ta phải “bán” hoặc yêu cầu họ sử dụng sản phẩm của mình.

Sự gắn kết với khách hàng

Bằng cách thu hẹp một cách thận trọng thị trường nhằm ưu tiên gia tăng chất lượng can dự và phản hồi từ khách hàng, chúng ta có thể xây dựng sự gắn kết, mối quan hệ và sự trung thành của những người tiếp nhận sản phẩm đầu tiên. Ai cũng thích được cảm thấy mình là một phần của điều gì đó duy nhất và đặc biệt.

PHÁT TRIỂN SỰ THẤU HIỂU KHÁCH HÀNG: ĐÔI KHI CÂU TRẢ LỜI NẰM NGAY TRONG TRỤ SỞ CỦA CÔNG TY BẠN

Hiệp hội Dược sĩ Hoàng gia Anh biết rằng cơ sở dữ liệu thuốc y tế của họ tốt nhất thế giới. Họ cũng biết rằng nó phải có nhiều công dụng hơn chứ không chỉ là một đống sách im lìm. Nhưng họ nên bắt đầu từ đâu? Thay vì suy đoán, hoặc đầu tư lớn để sản xuất một sản phẩm, hay cố gắng đạt đến một thỏa thuận mà không có sản phẩm, họ sử dụng một tài sản quan trọng khác của mình, đó là một trụ sở đầy các dược sĩ. Họ nhanh chóng tạo ra các nguyên mẫu, kiểm thử người dùng với các dược sĩ làm việc cho Hiệp hội, và nghiên cứu sản phẩm với các nhà thuốc gần đó. Qua đó, họ có thể nhanh chóng tập trung nỗ lực vào chương trình kiểm tra khả năng tương tác giữa các loại thuốc kê đơn. Và cuối cùng, họ dễ dàng đưa các dữ liệu đó vào sử dụng rộng rãi trên toàn thế giới. Bằng cách bắt đầu bằng một chương trình mà chính họ sẽ sử dụng, họ có thể hiểu được những gì mà các khách hàng quốc tế có thể muốn và từ đó xây dựng được một công cụ tiếp thị tuyệt vời.

Bằng việc duy trì cơ sở khách hàng ban đầu ở quy mô nhỏ – không theo đuổi những con số hão huyền, quá to hay quá nhanh – chúng ta buộc bản thân phải đơn giản hóa công việc và duy trì sự gần gũi với các khách hàng trên từng bước phát triển. Điều này cho phép các nhóm có thêm thời gian với khách hàng để lắng nghe, xây dựng niềm tin và giữ chân những người tiếp nhận đầu tiên mà chúng ta sẵn sàng giúp đỡ.

Hãy nhớ rằng, đạt được những con số to tát không có nghĩa là đã thắng đậm; đáp ứng những nhu cầu chưa được đáp ứng và làm hài lòng khách hàng mới thực sự là thành công.

Xây dựng một chuỗi câu hỏi chứ không phải chuỗi yêu cầu

Bản năng của các nhóm sản phẩm, sau khi thẩm định xong một vấn đề hoặc một giải pháp, là bắt đầu xây dựng tất cả các yêu cầu cho một giải pháp hoàn chỉnh, đầy đủ chức năng và có thể mở rộng dựa trên những thiếu sót trong các MVP của họ. Điều nguy hiểm của cách tiếp cận này là nó ngăn cản chúng ta phát triển sản phẩm dựa trên phản hồi của khách hàng.

Trong giai đoạn đầu, chúng ta vẫn đang học hỏi chứ chưa phải kiếm tiền. Vì vậy, điều quan trọng là không nên giới hạn những lựa chọn của mình bằng cách dồn thời gian, nhân lực và đầu tư vào việc xây dựng những tính năng có thể không tạo ra kết quả mà khách hàng mong muốn. Chúng ta phải chấp nhận rằng mọi giả định đều phải được kiểm thử, không ngừng tìm cách xác định lĩnh vực mà mình không rõ nhất và thực hiện các thử nghiệm để học hỏi thêm. Để ngăn việc sử dụng cách tiếp cận này, hãy thúc đẩy những gì không phát sinh, tức là xây dựng một chuỗi những kịch bản về cách mà chúng ta có thể tiếp tục tạo ra sản phẩm của mình.

Chuỗi kịch bản này sẽ là một danh sách những giả thiết cần được kiểm thử, chứ không phải một danh sách những yêu cầu cần thực hiện. Khi khen thưởng các nhóm về khả năng đáp ứng các nhu cầu, sẽ dễ dẫn đến tình trạng phát triển nhanh chóng các sản phẩm có các tính năng không cần thiết, làm gia tăng tính phức tạp, chi phí bảo dưỡng và hạn chế khả năng thay đổi. Kết quả kinh doanh chứ không phải các tính năng được đưa ra, mới là thước đo của thành công. Chuỗi kịch bản của chúng ta là một loạt các câu hỏi mà chúng ta cần kiểm thử để giảm sự bất trắc và gia tăng hiểu biết về các cơ hội tăng trưởng.

XÂY DỰNG BẢN ĐỒ NHỮNG CÂU CHUYỆN KỂ VỀ HÀNH TRÌNH TẦM NHÌN CỦA CHÚNG TA

Bản đồ câu chuyện (story map) là công cụ được Jeff Patton phát triển và giải thích trong cuốn sách User Story Mapping (tạm dịch: Lập bản đồ câu chuyện người dùng). Ông giải thích: “Phần mềm của bạn có một xương sống và bộ xương sườn – và bản đồ của bạn thể hiện điều đó.”

Các bản đồ kể chuyện giúp lập kế hoạch và xác định ưu tiên bằng cách hình dung tổng thể về giải pháp (xem Hình 5-3). Bản đồ kể chuyện không được thiết kế để tạo ra những câu chuyện hay xây dựng một kế hoạch ra mắt sản phẩm mà là để tìm hiểu các mục tiêu của khách hàng và những việc-cần-phải-làm. Các bản đồ kể chuyện là một phương tiện hiệu quả để truyền tải câu chuyện về giải pháp của chúng ta nhằm thu hút nhóm làm việc và các bên liên quan, qua đó sẽ nhận được phản hồi của họ. Bằng cách giới thiệu những bản đồ kể chuyện và kể lại câu chuyện về giải pháp đó, chúng ta đảm bảo được rằng mình không bỏ qua bất kỳ thành tố quan trọng nào. Đồng thời, chúng ta học hỏi được tối đa bằng cách xác định những giả thiết rủi ro nhất để kiểm thử trong khi giảm thiểu lãng phí và bỏ qua những giải pháp quá phức tạp nhưng không đáp ứng được nhu cầu của khách hàng mà MVP của chúng ta đã chỉ ra.

Hình 5-3. Một bản đồ câu chuyện người dùng

Khi chúng ta bắt đầu củng cố, tích hợp và tự động hóa việc sản xuất sản phẩm, nó tác động đến khả năng chúng ta có thể thích nghi nhanh chóng với những gì mà mình đang khám phá, thông thường là sẽ hạn chế khả năng phản ứng và thay đổi của chúng ta. Trong Đường chân trời 3, chúng ta phải không ngừng làm việc để tránh phức tạp hóa sản phẩm bằng cách tăng cường các dịch vụ, khả năng hoặc các tiến trình thủ công hiện tại để đem lại giá trị cho khách hàng. Mục đích không phải là tách khỏi khách hàng. Chúng ta muốn đảm bảo rằng chúng ta và khách hàng không ngừng tương tác. Nếu chỉ tối ưu hóa việc xây dựng mà không liên tục kiểm thử các giả định của mình với khách hàng, chúng ta có thể bỏ qua những vấn đề, các kinh nghiệm và thành công thực thụ – điều mà những hiểu biết thực sự thường đem lại.

Nếu muốn học hỏi, chúng ta phải đồng cảm với người dùng và trải nghiệm cảm xúc của họ. Khi khách hàng có một vấn đề mà chúng ta có thể giải quyết một cách thủ công, hãy làm như vậy càng lâu càng tốt. Khi chất lượng dịch vụ khách hàng giảm hoặc chúng ta không thể kiểm soát nhu cầu của khách hàng, hãy cân nhắc đưa ra các tính năng có thể giúp giải quyết những nút thắt cổ chai nổi lên trong khi lượng sử dụng sản phẩm gia tăng.

LƯU Ý

Thúc đẩy sự đổi mới từ cơ sở

Những kỹ thuật và các biện pháp không thể mở rộng không những cần thiết mà còn có thể là một chất xúc tác cho sự thay đổi trong văn hóa của tổ chức. Nếu chứng minh được mình có thể kiểm thử các ý tưởng một cách nhanh chóng, ít tốn kém và an toàn, chúng ta sẽ giúp xây dựng sự tự tin cho các nhân viên khác trong tổ chức rằng việc thử nghiệm là khả thi và kết quả sẽ là một sự thay đổi lâu dài cho điều tốt đẹp hơn trong văn hóa của chúng ta.

Sử dụng các biện pháp khám phá

Nhìn chung, chúng ta ưa thích các nguyên tắc của Hệ thống Sản xuất Toyota bằng cách “tăng chất lượng” của phần mềm, nội dung được thảo luận rất dài trong Chương 8. Tuy nhiên, trong khi khám phá, có sự căng thẳng giữa nhu cầu thử nghiệm bằng các MVP với việc gia tăng chất lượng thông qua các biện pháp như biện pháp kiểm thử tự động.

Khi bắt đầu thẩm định một ý tưởng sản phẩm mới hoặc một tính năng mới trong một sản phẩm hiện hành, chúng ta muốn thử càng nhiều ý tưởng càng nhanh càng tốt. Lý tưởng là có thể làm vậy mà không phải viết một phần mềm nào cả. Nhưng nếu viết phần mềm, không nên dành quá nhiều thời gian để xây dựng những kiểm thử chấp nhận⁴ và tái cấu trúc mã nguồn. Chúng ta sẽ, như Martin Fowler đề cập, tích lũy một cách thận trọng và khôn ngoan các khoản nợ kỹ thuật⁵ để vận hành các thử nghiệm và hoàn thành việc thẩm định.

⁴ Kiểm thử chấp nhận (acceptance test): Là kiểm thử được tiến hành nhằm xác định xem liệu các yêu cầu cụ thể đối với đối tượng được kiểm thử có được đáp ứng hay không. (BTV)

5 Khoản nợ kỹ thuật (technical debt): Là khái niệm trong phát triển phần mềm, phản ánh những chi phí/công việc phải làm lại do ban đầu nhà phát triển chọn giải pháp dễ dàng thay vì giải pháp tốt hơn nhưng kéo dài thời gian hơn. (BTV)

Tuy nhiên, nếu sản phẩm thành công, chúng ta sẽ bế tắc với cách tiếp cận này. Có lẽ một hoặc hai năm sau (tùy thuộc vào ngưỡng chịu đựng của chúng ta), những thay đổi sẽ trở nên khó khăn và tốn thời gian, còn sản phẩm sẽ trở nên tồi tệ với nhiều nhược điểm và hoạt động kém. Chúng ta thậm chí có thể phải bước vào giai đoạn mà chúng ta gọi là Đại Cải tổ (Big Rewrite).

Lời khuyên của chúng tôi là thế này. Có hai biện pháp cần được tin tưởng ngay từ đầu sẽ cho phép chúng ta giảm khoản nợ kỹ thuật sau đó: Sự tích hợp liên tục và một lượng nhỏ những đơn vị cơ bản và những kiểm thử về hành trình người dùng⁶. Thời điểm mà một sản phẩm (nếu chúng ta ở trong Đường chân trời 3) hoặc một tính năng (trong Đường chân trời 2) chuyển từ một thử nghiệm đến mức thẩm định xong, chúng ta cần bắt đầu giảm mạnh nợ kỹ thuật. Về cơ bản điều đó có nghĩa là bổ sung các kiểm thử hành trình người dùng, triển khai các biện pháp kiến trúc tốt như là mô đun hóa và chắc chắn rằng tất cả các mã nguồn mới về tính năng đều sử dụng việc phát triển dựa trên kiểm thử (trước đó, chắc chắn các kỹ sư giỏi đã sử dụng quy trình phát triển hướng kiểm thử TDD (Test-driven development⁷).

6 Hành trình người dùng (user-journey): Là những trải nghiệm mà một người có được khi sử dụng/tương tác với điều gì đó (thường nói về phần mềm). (BTV)

7 Là một quy trình phát triển phần mềm dựa trên sự lặp lại của một chu kỳ phát triển rất ngắn: thay cho các yêu cầu kỹ thuật là các trường hợp kiểm thử thật cụ thể, sau đó phần mềm được cải thiện chỉ để vượt qua các bài kiểm thử mới. (ND)

Khi buộc bản thân phải làm điều gì đó không tự nhiên với các kỹ sư – tìm ra mã nguồn chưa tốt và đem đi thẩm định từ sớm – chúng ta phải chuyển mạnh sang hướng khác, bác bỏ động lực và chuyển trọng tâm từ việc tạo ra sản phẩm đúng sang điều chỉnh sản phẩm cho đúng. Không cần phải nói, điều này rõ ràng đòi hỏi phải có kỷ luật nghiêm khắc.

Lựa chọn ở điểm nào trong vòng đời của sản phẩm hoặc tính năng để giảm nợ kỹ thuật là một nghệ thuật. Nếu bạn phát hiện (như nhiều người khác cũng vậy) rằng bạn đã đi quá xa trên đường tích lũy nợ kỹ thuật, hãy cân nhắc những lựa chọn thay thế cho Đại Cải tổ được mô tả trong Chương 10.

Động lực tăng trưởng

Trong cuốn Khởi nghiệp tinh gọn, Eric Ries nhận định có ba chiến lược then chốt cho tăng trưởng – và hãy chọn một:

Chiến lược lan truyền

Bao gồm bất kỳ một sản phẩm nào khuyến khích các khách hàng mới đăng ký như là một hiệu ứng phụ cần thiết của việc sử dụng thông thường của các khách hàng hiện có: Facebook, MySpace, AIM/ICQ, Hotmail, Paypal. Các thông số chính là sự thu hút và giới thiệu, kết hợp thành hệ số lan truyền đang rất nổi tiếng hiện nay.

Chiến lược trả tiền

Là khi chúng ta sử dụng một phần giá trị vòng đời của mỗi khách hàng và đưa nó trở lại thành sự thu hút bằng tiền qua các thủ thuật tiếp thị qua công cụ tìm kiếm, quảng cáo banner trên các website, quan hệ công chúng, tiếp thị liên kết, v.v.. Giá trị vòng đời khách hàng và tổng chi phí thu hút khách hàng là yếu tố quyết định lợi nhuận hoặc tỷ lệ tăng trưởng, và việc cân bằng hai yếu tố này sẽ được đánh giá cao. Giữ chân khách hàng là mục đích then chốt trong mô hình này. Các ví dụ bao gồm Amazon và Netflix.

Chiến lược kết dính

Có nghĩa là điều gì đó khuyến khích khách hàng trở nên nghiện sản phẩm, và dù cách chúng ta thu hút khách hàng mới là gì đi nữa thì chúng ta đều có xu hướng giữ chân họ. Thông số cho sự kết dính là “tỷ lệ khách hàng rời bỏ” – khách hàng không còn sử dụng sản phẩm hay dịch vụ của chúng ta. Điều này có thể dẫn đến sự tăng trưởng lũy thừa. Ví dụ như eBay, sự kết dính là kết quả của hiệu ứng mạng lưới8 tuyệt vời trong hoạt động kinh doanh của họ.

8 Hiệu ứng mạng lưới (network effect): Là hiện tượng xảy ra khi sản phẩm/dịch vụ càng gia tăng giá trị khi càng có nhiều người sử dụng. (BTV)

Tuy nhiên, đối với các doanh nghiệp, còn có những phương án phát triển khác cần cân nhắc:

Chiến lược mở rộng

Là việc xây dựng một mô hình kinh doanh ban đầu có tính thích nghi, theo đó chúng ta có thể chỉ cần tập trung cho tăng trưởng và mở rộng bằng cách mở ra những lĩnh vực, những loại sản phẩm và sản phẩm phụ trợ mới. Amazon đã thực thi chiến lược này một cách xuất sắc, chuyển từ việc bán sách thành một cửa hàng thương mại điện tử cung cấp những danh mục bán lẻ mới. Với chiến lược phát triển này, thị trường mục tiêu ban đầu cần phải đủ lớn để hỗ trợ nhiều giai đoạn tăng trưởng khác theo thời gian.

Chiến lược xây dựng nền tảng

Sau khi xây dựng thành công sản phẩm cốt lõi, chúng ta chuyển nó thành một nền tảng với một “hệ sinh thái” xung quanh bao gồm những sản phẩm và dịch vụ hỗ trợ được phát triển bởi các nhà cung cấp trong và ngoài tổ chức. Microsoft đã làm được điều này với Windows bằng cách tạo ra MS Office, Money và các gói bổ trợ khác, trong đó có những gói do các công ty bên ngoài phát triển. Các ví dụ khác về nền tảng còn có AppStore của Apple, Web.taisachnhanh.cloud của Salesforce và các dịch vụ Marketplace và Web Services của Amazon.

Danh tiếng của các sản phẩm, công cụ và biện pháp hay, ở cả trong và ngoài tổ chức, đều luôn được truyền khẩu nhờ vào giá trị thực sự thuyết phục của chúng và một thương hiệu mà khách hàng tự hào khi sử dụng. Nếu sự tăng trưởng của chúng ta bắt nguồn từ khách hàng thì điều này sẽ xảy ra mà ta không cần phải đầu tư. Nếu không làm như vậy, chúng ta sẽ bị hạn chế bởi nỗ lực cần thiết để khám phá, chuyển đổi và phục vụ khách hàng của mình một cách thủ công.

Cuối cùng, sản phẩm của chúng ta là động lực then chốt cho sự tăng trưởng. Nếu chúng ta xây dựng một giải pháp thực sự thuyết phục giúp giải quyết một nhu cầu của khách hàng và họ thực sự yêu thích nó, họ sẽ sử dụng nó. Ấn tượng hơn là họ sẽ trở thành những người ủng hộ và khuyến khích những người khác sử dụng, và như vậy họ chính là nhóm bán hàng tốt nhất mà chúng ta có thể mong ước để đi đến thành công.

CHUYỂN TIẾP GIỮA CÁC ĐƯỜNG CHÂN TRỜI ĐỂ TĂNG TRƯỞNG VÀ CHUYỂN ĐỔI

Trong Chương 2, chúng ta đã thảo luận về việc các tổ chức phải quản lý đồng thời cả ba đường chân trời. Khả năng nhận thức, chuyển tiếp và chuyển đổi các sáng kiến qua các cung đường này, như được thể hiện trong Hình 5-4, chính là chìa khóa cho sự thành công, khả năng thích ứng và sự tồn tại lâu dài của tổ chức trong tương lai.

Như chúng ta mô tả trong Chương 3, chính Đường chân trời 2 và 3 là nơi cần nhất sự ủng hộ của ban lãnh đạo. Những đường này có tính bất trắc cao hơn và doanh thu thấp hơn, vì vậy chúng dễ dàng bị nghiền nát nếu không được quản lý một cách độc lập với Đường chân trời 1.

Chúng ta phải nhận thức được các nguy cơ ở mỗi giai đoạn, bao gồm việc chuyển tiếp không đúng thời điểm và lựa chọn chiến lược sai cho mỗi đường chân trời.

Hình 5-4. Tỷ lệ danh mục sản phẩm cho ba đường chân trời đổi mới theo thời gian

PHÁT TRIỂN TINH GỌN VÀ HOẠT ĐỘNG TINH GỌN THEO TƯ DUY CỦA STEVE BELL

Tư duy tinh gọn thường được gắn với hành động vì nó bắt nguồn từ Hệ thống Sản xuất Toyota (TPS) và đã được chấp nhận rộng rãi trong việc tổ chức sản xuất. Nhưng một phần không nhỏ thành công lâu dài của Toyota cũng là nhờ vào việc áp dụng các nguyên tắc tinh gọn để phát triển một cách nhanh chóng và hiệu quả các sản phẩm mới, hấp dẫn, có chất lượng cao và chi phí hợp lý. Toyota đã chứng tỏ rằng một doanh nghiệp tiếp nhận tư duy tinh gọn một cách liên tục trong suốt quá trình phát triển và hoạt động thì có thể giành được lợi thế cạnh tranh lâu dài.

Phát triển và hoạt động tinh gọn có quan hệ với nhau và bổ sung cho nhau, nhưng rất khác nhau về bản chất. Hoạt động tinh gọn nhấn mạnh việc tiêu chuẩn hóa và giảm lãng phí, giảm bất trắc và biến động để tạo ra các tiến trình hiệu quả nhằm sản xuất những sản phẩm có chất lượng và ổn định. Trái lại, phát triển tinh gọn sử dụng tính bất trắc và biến động từ rất sớm trong tiến trình lập kế hoạch để học hỏi thông qua các thử nghiệm, đặc biệt là từ những thất bại, để tìm ra cách hiệu quả nhất để giải quyết các vấn đề và thúc đẩy đổi mới.

Tuy nhiên, ở đây tồn tại một nghịch lý: Phát triển tinh gọn, điều cần đến sự biến động và bất trắc, lại dựa vào các phương pháp làm việc tiêu chuẩn để hình thành các giả thiết đổi mới và vận hành những thử nghiệm nhất quán và tái lặp nhằm giảm thiếu lãng phí nguồn lực và thời gian, trong khi tối đa hóa tính sáng tạo và giá trị.

Ví dụ, phát triển tinh gọn liên quan chặt chẽ và liên tục đến Tiếng nói của Khách hàng (VOC – Voice of the Customer⁹) ở các gemba (địa điểm, cả thực tế và ảo, nơi công việc được hoàn thành) sử dụng thiết kế đa mục tiêu (set-based design¹⁰) và tái lặp để tăng cường học hỏi và nhanh chóng tạo ra một sản phẩm có giả thiết giá trị hợp lý. Các biện pháp tinh gọn tiêu chuẩn khác như phương pháp giải quyết vấn đề A3, quản lý trực quan và lập bản đồ chuỗi giá trị là những biện pháp có ích trong thiết kế phát triển, giúp cải thiện tốc độ đưa ra thị trường trong khi giảm chi phí R&D và rủi ro cho doanh nghiệp.

9 Là những hiểu biết về nhu cầu, kỳ vọng, sở thích của khách hàng thu thập được qua hoạt động hỏi thông tin khách hàng trực tiếp hoặc gián tiếp. (BTV)

¹⁰ Khác với thiết kế một mục tiêu (point-based design), thiết kế đa mục tiêu thực hiện đồng thời nhiều phương án và loại bỏ dần các phương án trong quá trình học hỏi và điều chỉnh. (BTV)

Khi đã có một sản phẩm hay dịch vụ khả thi mới, doanh nghiệp có thể sử dụng các khả năng hoạt động tinh gọn của mình để ra mắt thị trường một cách nhanh chóng, hiệu quả và thẩm định giả thiết tăng trưởng. Đây là lúc mà nhiều doanh nghiệp khởi nghiệp tinh gọn hoặc là mất thị trường cho những doanh nghiệp bắt chước nhanh hoặc là bị thâu tóm bởi các doanh nghiệp lớn hơn có khả năng hoạt động tinh gọn nhằm nhanh chóng đến với thị trường, sớm khai thác lợi nhuận và giành lấy sự thống trị thương hiệu. Mặc dù đối với các doanh nghiệp lớn, chiến lược thâu tóm các doanh nghiệp khởi nghiệp để tạo nguồn lực đổi mới chắc chắn là điều khả thi, nhưng họ cũng muốn tăng cường khả năng đổi mới ở chính bên trong tổ chức của mình.

Như vậy, phát triển tinh gọn giúp tạo ra các sản phẩm và dịch vụ đổi mới thông qua các hoạt động tinh gọn và đưa đến tay người tiêu dùng một chuỗi giá trị liên tục, tương tự như DevOps¹¹ diễn ra trong hoạt động phát triển phần mềm. Khi một doanh nghiệp có khả năng tích hợp và khai thác dòng ý tưởng nhanh chóng về tính toán giá trị, thì lợi nhuận từ các sản phẩm chín muồi có thể được dùng để đầu tư cho đổi mới liên tục, tạo ra một vòng xoáy phát triển được mô tả trong Hình 5-5.

¹¹ DevOps, viết tắt của Development and Operations (Phát triển và Vận hành), là một thuật ngữ trong phát triển phần mềm để chỉ mối liên quan giữa quá trình phát triển và quá trình vận hành. Mục đích của DevOps là để thay đổi và cải tiến mối quan hệ giữa hai quá trình này. (ND)

Hình 5-5. Vòng tròn phát triển sự đổi mới của Steve Bell

Khi cố gắng vượt qua Đường chân trời 3, những dấu hiệu về sự hài lòng và tiếp tục tham gia của khách hàng rất quan trọng đối với việc quản lý sự tăng trưởng trong tương lai. Sau khi tìm được khách hàng, học cách giải quyết các nhu cầu và tự tin về việc đáp ứng yêu cầu của họ, chúng ta nên tìm cách mở rộng cơ sở khách hàng bằng cách gia tăng các địa điểm, kênh bán hàng và các gói khuyến mại.

Trong giai đoạn Khám phá, chúng ta kiểm tra sự phù hợp giữa sản phẩm và thị trường, cơ bản là thông qua các giải pháp tìm hiểu khách hàng ban đầu của mình. Giai đoạn Khai thác là khi chúng ta đưa ra phương hướng và xây dựng mô hình kinh doanh thu hút lượng khách hàng lớn hơn.

Năm yếu tố quan trọng cho sự tăng trưởng khi chuyển tiếp từ giai đoạn Khám phá sang giai đoạn Khai thác là:

Thị trường

Điều cấp bách là phải chọn đúng thị trường. Sẽ là lý tưởng nếu có nhiều khách hàng tiềm năng ủng hộ khao khát tăng trưởng của chúng ta; phải xác định được những yếu tố giúp chúng ta thành công với những người tiếp nhận đầu tiên, sau đó tìm cách phát hiện và thu hút những nhóm khách hàng tương tự nhưng với quy mô lớn hơn. Hiểu biết mà chúng ta có được qua làm việc với những người tiếp nhận đầu tiên là chìa khóa để tìm kiếm những nhóm khách hàng mới. Những người tiếp nhận đầu tiên chắc chắn cũng sẽ rỉ tai với những người khác để lan truyền trải nghiệm của họ với sản phẩm của chúng ta, qua đó thúc đẩy sản phẩm “vượt qua sự cách biệt” để được chấp nhận rộng rãi hơn.

Mô hình tiền tệ hóa

Chúng ta phải quyết định đâu là cách tốt nhất để đạt được giá trị từ các đề xuất của mình vì điều đó giúp xác định về cơ bản những gì sẽ thúc đẩy doanh thu cho mô hình kinh doanh của chúng ta. Sau đó nó cũng khó có thể thay đổi.

Sự chấp nhận của khách hàng

Làm thế nào để khách hàng đồng hành cùng với sản phẩm? Chúng ta phải cẩn thận để không phải thực hiện sự nhượng bộ đáng kể nào về sản phẩm và giá cả cho bất kỳ nhóm khách hàng đơn lẻ nào để có thể nhận được một đơn hàng lớn. Chúng ta phải luôn trung thành với tầm nhìn sản phẩm và quản lý được sức ép, nhu cầu của bất kỳ nhóm khách hàng đơn lẻ nào có thể làm hạn chế khả năng tiếp tục tăng trưởng.

Hãy quên đi những cuộc ra mắt hoành tráng kiểu Vụ nổ lớn (big bang) Hãy đảm bảo an toàn: Tiếp tục kiểm thử và thẩm định sản phẩm, kiềm chế sự bùng phát và làm việc với lượng nhỏ hơn các khách hàng tiêu biểu. Xây dựng động lực thông qua các buổi ra mắt sản phẩm giai đoạn alpha và beta¹² với các phân khúc khách hàng mục tiêu. Khi tự tin, hiểu biết và thành công hơn, chúng ta sẽ mở rộng cơ sở khách hàng. Sẽ là lý tưởng nếu khách hàng đem những vấn đề cần giải quyết đến với chúng ta mà chúng ta không phải tìm cách đẩy sản phẩm mới đến họ.

¹² Thuật ngữ trong phát triển phần mềm, chỉ hai giai đoạn kiểm thử sản phẩm trong nhóm khách hàng tiềm năng/nhóm kiểm thử nội bộ (alpha test), tiếp đến là với một lượng khách hàng thực tế ở quy mô giới hạn (beta test) để đánh giá khả năng tiếp nhận sản phẩm của người dùng. (BTV)

Thu hút nhóm cùng tham gia

Chúng ta phải làm tất cả những gì có thể để đảm bảo cả nhóm cùng nhau bảo vệ văn hóa, tốc độ học hỏi và kiến thức cần thiết. Chúng ta không muốn xây dựng một bức tường ngăn cách giữa các nhóm đổi mới và các nhóm hoạt động. Sự phối hợp, hướng tới học hỏi và vì sự phát triển của tổ chức là chìa khóa để tạo ra đòn bẩy thúc đẩy văn hóa đổi mới khi chúng ta bắt đầu mở rộng và tuyển dụng thêm các thành viên mới cho nhóm.

Khi xem xét những cải thiện về tiến trình và lựa chọn công cụ, chúng ta cũng áp dụng những nguyên tắc tương tự để phát hiện người dùng mục tiêu, đánh giá và tìm kiếm lợi nhuận, sự chấp nhận của người dùng, tránh những cuộc giới thiệu sản phẩm kiểu “vụ nổ lớn” và thúc đẩy sự giam gia của cả nhóm.

CẦN THỜI GIAN ĐỂ ĐỔI MỚI: TỪ ĐẤU GIÁ ĐẾN THƯƠNG TRƯỜNG

Những cuộc đấu giá của Amazon (sau này được gọi là zShop) được ra mắt vào tháng 3 năm 1999 để đối phó với thành công của eBay. Trang này được phát triển dựa chủ yếu vào trang chủ, trang phân loại và sản phẩm cá nhân. Mặc dù vậy, một năm sau buổi ra mắt, zShop chỉ giành được 3,2% thị phần của thị trường đấu giá trực tuyến so với 58% của eBay, và sau đó thì phá sản.

Tháng 11 năm 2000, zShop được đổi tên thành Amazon Marketplace, cung cấp giá cạnh tranh cho các sản phẩm của bên cung cấp thứ ba và kèm theo là danh sách các sản phẩm tiêu chuẩn. Chiến lược này, ban đầu được thúc đẩy do nhu cầu cạnh tranh với eBay, được điều chỉnh để gắn với trọng tâm chiến lược duy trì giá thấp của Amazon.

Mở rộng thêm mô hình này, Amazon cung cấp hoạt động bán các sản phẩm đã qua sử dụng thông qua Marketplace, tạo ra một dòng doanh thu khác mà không ảnh hưởng đến chuỗi nguồn cung của mình. Quảng cáo, đóng gói và vận chuyển hàng hóa là do các nhà cung cấp thực hiện riêng rẽ, còn Amazon thu một phần lợi nhuận của thương vụ vì đã cung cấp các kênh bán hàng với chi phí tối thiểu.

Năm 2012, dịch vụ Marketplace của Amazon đã tạo ra 12% doanh thu với tổng doanh số định kỳ tăng 32% so với năm trước đó.

Thông qua việc xem lại phương pháp xác định và đánh giá những hiểu biết được thẩm định, chúng ta có thể bắt đầu kiểm thử và giới thiệu nếu và khi mà các sáng kiến của chúng ta bắt đầu có khả năng thu hút. Bằng cách liên tục thử nghiệm với khách hàng và thay đổi Thông số chính với chi phí thấp và tốc độ nhanh nhất, chúng ta có thể hạn chế mức đầu tư, giảm rủi ro liên quan và tối đa hóa hiểu biết. Cách tiếp cận dựa trên bằng chứng đối với việc phát triển sản phẩm giúp đảm bảo an toàn, cung cấp điều kiện và cơ sở hành động cho các bên liên quan, trở thành một chất xúc tác để giúp thay đổi trong tổ chức lớn hơn.

KẾT LUẬN

Kế toán đổi mới cung cấp một khuôn khổ để đánh giá sự tiến bộ trong bối cảnh Đường chân trời 3, tức là trong các điều kiện cực kỳ bất trắc. Nó được thiết kế để thu thập những dấu hiệu dẫn dắt tăng trưởng của ý tưởng trong tương lai, qua đó chúng ta có thể loại bỏ những gì sẽ không thành công trong Đường chân trời 2.

Chúng ta đã xác định ba điểm then chốt cần xem xét trong giai đoạn này. Thứ nhất, chúng ta phải tìm ra những khách hàng có thể đóng vai trò là người đồng sáng tạo ra giá trị. Chúng ta sử dụng phản hồi của họ để thử nghiệm và làm rõ tỷ lệ giá trị trước khi hướng đến một thị trường lớn hơn. Thứ hai, chúng ta tập trung vào việc học hỏi hơn là doanh thu bằng cách tập trung vào lượng hẹp khách hàng và thẩm định từng giả định mà giải pháp của chúng ta đưa ra. Chúng ta không cần tạo ra các yêu cầu mà cần trả lời các câu hỏi về chức năng được mong muốn của sản phẩm. Cuối cùng, chúng ta tập trung vào việc thu hút sự tham gia của người dùng hơn là sớm đạt được lợi nhuận, bởi có nhiều người dùng cảm thấy hài lòng hơn có nghĩa là chúng ta sẽ có doanh thu (hoặc bất cứ giá trị nào mà chúng ta hy vọng tạo ra cho tổ chức). Khi đã cải thiện được hiểu biết về người dùng và cơ hội sản phẩm, chúng ta có thể quyết định một mô hình phát hành sản phẩm để đảm bảo sản phẩm tiếp tục thành công.

Nhiều ý tưởng sẽ không thể trở thành một sản phẩm hòa hợp với thị trường. Đối với những ý tưởng khả thi, thì sự điều chỉnh là cần thiết. Thái độ và các nguyên tắc quản lý cần thiết cho thành công trong Đường chân trời 2 cơ bản khác với trong Đường chân trời 3. Phần III sẽ trình bày cách phát triển một tổ chức tập trung vào việc tạo ra sản phẩm đúng cách để có thể tin tưởng rằng chúng ta đang tạo ra được sản phẩm đúng.

Câu hỏi dành cho độc giả:

◆ Khách hàng và các thông số kinh doanh nào sẽ nằm trong danh sách đổi mới của bạn?

◆ Ai là bên liên quan chính, và ảnh hưởng của họ trong mỗi giai đoạn đường chân trời cho sản phẩm của bạn là gì? Bạn có kế hoạch nào để thu hút họ và tạo ra sự gắn kết?

◆ Bạn có kế hoạch tiến hành các thử nghiệm và thẩm định các giả thiết mô hình kinh doanh với khách hàng không? Bạn nhận diện và ưu tiên cho chúng như thế nào?

◆ Bạn có thể thu thập dữ liệu để kiểm thử với thị trường mục tiêu của mình như thế nào để tốn ít chi phí và nhanh nhất có thể?

◆ Bạn đặt ra tiêu chí nào khi chuyển một sản phẩm từ Đường chân trời 3 sang Đường chân trời 2?

Phần IIIKHAI THÁC

Dự đoán lúc nào cũng khó, đặc biệt khi dự đoán về tương lai.

− NIELS BOHR

Trong Phần II, chúng tôi đã chỉ ra cách khám phá các cơ hội mới – có thể là các sản phẩm tiềm năng hoặc các công cụ nội bộ và dịch vụ. Trong phần này, chúng tôi thảo luận về cách khai thác các ý tưởng đã được thẩm định. Như được thảo luận trong Chương 2, hai lĩnh vực này yêu cầu những cách tiếp cận hoàn toàn khác nhau trong quản lý và thực thi. Tuy nhiên, cả hai đều cần thiết – và thực sự bổ trợ cho nhau – nếu chúng ta muốn cân bằng một cách hiệu quả danh mục nguồn của doanh nghiệp và thích ứng với một môi trường kinh doanh không ngừng thay đổi.

Chúng tôi hy vọng rằng bạn đang đọc phần này vì bạn đã thực hiện thành công giai đoạn Khám phá, nhưng cũng có thể chỉ là bạn đang tham gia vào một chương trình làm việc lớn trong một doanh nghiệp được thành lập theo cách truyền thống. Vì vậy, phần này của cuốn sách chủ yếu mô tả biện pháp thay đổi phương pháp lãnh đạo và quản lý các chương trình làm việc quy mô lớn bằng cách gia tăng quyền lực cho nhân viên và tăng tốc quá trình giới thiệu sản phẩm giá trị và chất lượng cao đến khách hàng. Nhưng trước khi bắt đầu, chúng ta phải hiểu tình hình hiện nay của mình.

Trong môi trường doanh nghiệp, người ta thường ưu tiên cho các công việc đã được lập trình thông qua một tiến trình tập trung hóa hoặc kế hoạch hóa có dự trù ngân sách của từng bộ phận. Sau đó, các dự án đã được thông qua sẽ trải qua tiến trình phát triển trước khi được sử dụng hoặc đưa vào sản xuất. Ngay cả trong những tổ chức đã chấp nhận các phương pháp phát triển nhanh, chuỗi giá trị cần thiết cho việc hình thành một dự án thông thường cũng tương tự như mô hình “Thác nước-Scrum¹” được mô tả trong Hình III-1. Trong các trường hợp mà một hoặc hơn một các giai đoạn này được thuê ngoài, chúng ta cũng phải trải qua một tiến trình thâu tóm trước khi có thể tiến đến giai đoạn thiết kế và phát triển sau khi được phê duyệt. Do tiến trình này rất nặng nề nên chúng ta có xu hướng chất đống công việc lại và tạo ra những chương trình lớn làm gia tăng những rắc rối xuất phát từ kết cấu dự án.

¹ Cách tiếp cận kết hợp giữa mô hình thác nước mang tính tuần tự và tuyến tính với mô hình Scrum nhấn mạnh vào các yếu tố làm việc nhóm, sự tin cậy và hướng đến một mục tiêu được xác định rõ. (BTV)

Hình III-1: Mô hình Thác nước-Scrum

Mô hình thác nước dùng cho phát triển phần mềm với quy mô phù hợp này bắt nguồn từ khu liên hợp quân sự-công nghiệp của Mỹ hậu Thế chiến II, nơi mà phần mềm có giá trị quyết định đến việc xây dựng một thế hệ máy bay, hệ thống tên lửa và tàu vũ trụ mới mà khách hàng chủ yếu là Chính phủ Mỹ. Không phải do trùng hợp ngẫu nhiên mà thuật ngữ “kỹ thuật phần mềm” được nêu ra tại một hội nghị do NATO triệu tập năm 1968 để nghiên cứu cách chính thức hóa việc phát triển phần mềm quy mô lớn.

Mô hình dự án thác nước và tập trung hóa kiểu truyền thống được thiết kế thành một chu trình đơn giản hơn. Các sản phẩm không thể đem lại giá trị cho đến khi chúng được sản xuất hoàn thiện, chúng không cần thay đổi về chất theo các giai đoạn vòng đời của mình và chúng ta rất tự tin rằng sẽ không cần thay đổi đặc tính của chúng một cách đáng kể để có thể phản ứng trước những thông tin mới nắm được trong quá trình xây dựng sản phẩm.

Không có tiêu chí nào nói trên được áp dụng cho các hệ thống dựa trên phần mềm ngày nay, và sức mạnh của phần mềm xuất phát từ thực tế rằng việc hình thành và thay đổi phần mềm không tốn kém nhiều. Đặc biệt, do chúng ta thường hiểu sai về những giá trị mà người dùng nhận thấy trong các sản phẩm và hệ thống của ta, nên việc lập kế hoạch cho những chương trình lớn kéo dài nhiều tháng sẽ dẫn tới sự lãng phí và bất bình ghê gớm. Thay vì cố gắng dự đoán chính xác hơn về tương lai, chúng ta nên cải thiện khả năng thích ứng một cách nhanh chóng và hiệu quả với những thông tin mới.

Kết cấu hiện đại và nhanh-gọn mà chúng ta đưa ra để điều hành các chương trình làm việc quy mô lớn được thảo luận trong phần này là kết quả của quá trình hợp tác nghiên cứu với một số tổ chức có nhu cầu đưa hoạt động phát triển phần mềm ra khỏi đường găng (critical path²). Họ muốn xúc tiến nhanh với quy mô phù hợp, phát hiện từng tín hiệu nhỏ của thị trường và nhanh chóng khai thác chúng. Điều này cho phép họ cung cấp dịch vụ khách hàng tốt hơn, giảm chi phí xây dựng, phát triển sản phẩm đồng thời tăng chất lượng và tính ổn định của dịch vụ.

2 Đường găng là thuật ngữ chỉ một bộ công cụ và phương pháp quản lý dự án. Đường găng là chuỗi dài nhất gồm các hoạt động trong một kế hoạch dự án cần được hoàn thiện đúng thời hạn để dự án có thể được hoàn thành đúng hạn. Bất kỳ hoạt động nào bị trì hoãn sẽ khiến toàn bộ dự án bị trì hoãn. Phương pháp này giúp nhóm dự án tập trung vào những phần công việc quan trọng nhất. (BTV)

Có một vài khuôn khổ giải quyết việc đánh giá các phương pháp phát triển phần mềm linh hoạt. Nhìn chung, những khuôn khổ này đều khuyến khích các nhóm nhỏ thực hiện mô hình Scrum và bổ sung các cơ chế phối hợp công việc. Tuy nhiên, các nhóm này vẫn bị gắn chặt vào một chương trình phân giai đoạn và một tiến trình quản lý hồ sơ gần như không thay đổi so với mô hình quản lý dự án truyền thống. Họ vẫn áp dụng tư duy quản lý từ trên xuống và có xu hướng nhóm các công việc lại thành các đợt với chu trình kéo dài, vì vậy hạn chế việc sử dụng thông tin thu thập được để định hướng các quyết định tương lai. Cách tiếp cận của chúng ta khác những khuôn khổ này cũng như các khuôn khổ phân đoạn khác có tính truyền thống hơn ở một vài điểm quan trọng.

Sự khác biệt quan trọng nhất là thay vì đưa ra một bộ tiến trình và phương pháp thực hiện cụ thể, chúng ta tập trung vào việc thực hiện những cải tiến liên tục ở bậc lãnh đạo cấp cao để thúc đẩy sự phát triển của tổ chức và những tiến trình mà tổ chức sử dụng. Chúng ta không thể đặt cải tiến liên tục ở bên cạnh “biểu đồ lớn” mà đặt nó vào vị trí đầu tiên hoặc ở trung tâm. Điều này phản ánh thực tế rằng không có giải pháp nào phù hợp-cho-tất cả và rằng mọi tổ chức đều phải đối mặt với hàng loạt các tình huống khác nhau. Mọi tổ chức sẽ có con đường riêng để giải quyết những thay đổi gắn với các mục tiêu kinh doanh của mình; và để có kết quả lâu dài, chúng ta phải cho phép các nhóm kiểm thử mọi điều và tìm hiểu những gì có ích và không có ích cho chính họ.

Trong chương tiếp theo, chúng tôi sẽ trình bày những nguyên tắc phát triển sản phẩm nhanh-gọn với quy mô phù hợp, bao gồm:

• Thực thi một tiến trình cải tiến liên tục và không ngừng lặp lại ở cấp lãnh đạo với những kết quả cụ thể, rõ ràng và chính xác để tạo ra sự gắn bó cần thiết theo Yêu cầu Nhiệm vụ.

• Có phương pháp làm việc khoa học để đạt được các mục đích đầy thách thức, từ đó xác định và bỏ qua – hoặc tránh – những hoạt động không-tạo- thêm-giá trị.

• Liên tục đưa sản phẩm ra thị trường để giảm rủi ro của việc ra mắt sản phẩm, giảm vòng đời và tăng hiệu quả kinh tế khi làm việc trong các nhóm nhỏ.

• Phát triển một mô hình hỗ trợ linh hoạt cho các nhóm phối hợp trong tiếp cận khách hàng, những nhóm có quyền tự quyết cách thức làm việc nhằm đạt được kết quả ở cấp độ tổng quan.

• Giảm quy mô các nhóm và sử dụng cách tiếp cận thử nghiệm cho tiến trình phát triển sản phẩm.

• Tăng và mở rộng chu trình phản hồi để đưa ra những quyết định nhỏ hơn và thường xuyên hơn dựa trên những thông tin học hỏi được từ quá trình làm việc nhằm tối đa hóa giá trị khách hàng.

Chúng tôi cũng nêu một số ví dụ về các doanh nghiệp đã thực hiện những nguyên tắc này để tạo ra lợi thế cạnh tranh lâu dài và mô tả cách họ điều chỉnh bản thân trong tiến trình này.

Chương 6Cải tiến liên tục

Điều nghịch lý là khi tập trung vào sản xuất, các nhà quản lý hiếm khi thực hiện những cải tiến lâu dài. Trong khi đó, nếu tập trung vào chất lượng, họ có thể không ngừng cải tiến quá trình sản xuất.

− JOHN SEDDON

Trong nhiều doanh nghiệp, có sự phân biệt giữa người thiết kế và vận hành các hệ thống phần mềm (thường được gọi là “dân IT”) và những người quyết định phần mềm đó nên làm gì và đưa ra các quyết định đầu tư (thường được gọi là “doanh nhân”). Những tên gọi này là dấu tích của một kỷ nguyên lỗi thời trong đó IT được coi là một chi phí cần thiết để cải thiện tính hiệu quả của doanh nghiệp, chứ không phải là yếu tố tạo ra giá trị cho các khách hàng bên ngoài bằng cách xây dựng các sản phẩm và dịch vụ. Cách gọi này và sự phân biệt chức năng như vậy trở nên bế tắc trong nhiều tổ chức (vì giữa chúng có mối quan hệ và nếp nghĩ thường đi liền với mối quan hệ đó). Vì vậy, chúng tôi mong muốn từ bỏ sự phân biệt này. Trong các tổ chức hiệu năng cao ngày nay, những người thiết kế, xây dựng và vận hành các sản phẩm dựa trên phần mềm là một bộ phận tất yếu của doanh nghiệp; họ được trao cho – và chấp nhận – trách nhiệm về kết quả thu hút khách hàng. Tuy nhiên, rất khó có thể đạt đến trạng thái này, trong khi nếu quay lại với những cách làm việc cũ thì dễ dàng hơn nhiều.

Việc đạt được hiệu năng cao trong các tổ chức coi phần mềm là một lợi thế chiến lược phụ thuộc vào sự gắn kết giữa chức năng IT và phần còn lại của tổ chức, cùng với khả năng thực thi của IT. Đó là phần thưởng xứng đáng dành cho họ. Trong công trình nghiên cứu đăng tải trên tờ MIT Sloan Management Review, “Avoiding the Alignment Trap in Information Technology” (tạm dịch: “Tránh bẫy gắn kết¹ trong IT”), các tác giả đã điều tra 452 công ty và phát hiện ra rằng những công ty có hiệu năng cao (7% trong tổng số các công ty) chi phí cho IT ít hơn một chút so với mức trung bình trong khi vẫn đạt tỷ lệ tăng trưởng doanh thu cao hơn một cách đáng kể.

¹ Bẫy gắn kết chỉ quan điểm cho rằng IT phải gắn với mục tiêu kinh doanh thì mới tạo ra giá trị mà không biết rằng chỉ riêng sự gắn kết sẽ không đảm bảo cải thiện hiệu năng. (BTV)

Tuy nhiên, cách chuyển từ hiệu năng thấp sang hiệu năng cao là một vấn đề quan trọng. Các công ty có IT thiếu hiệu quả phải lựa chọn. Liệu họ nên theo đuổi sự gắn kết trước, hay cố gắng cải thiện khả năng hoạt động của mình? Các dữ liệu chỉ ra rằng các công ty có khả năng IT kém đạt kết quả tệ hơn khi theo đuổi sự gắn kết nhưng ưu tiên cho việc kinh doanh hơn là việc thực thi, ngay cả khi họ đầu tư thêm rất nhiều cho việc đó. Trái lại, các công ty có các nhóm kỹ sư làm tốt việc lập trình công việc và đơn giản hóa các hệ thống của mình lại đạt kết quả kinh doanh tốt hơn với chi phí thấp hơn nhiều, ngay cả nếu các khoản đầu tư IT của họ không gắn kết với các ưu tiên của doanh nghiệp.

Các nhà nghiên cứu kết luận rằng để đạt hiệu năng cao, những công ty dựa vào phần mềm cần tập trung trước hết vào khả năng thực thi, xây dựng các hệ thống đáng tin cậy và nỗ lực để không ngừng giảm tính phức tạp. Chỉ khi đó thì việc theo đuổi sự gắn kết với các ưu tiên kinh doanh mới đem lại hiệu quả.

Tuy nhiên, trong mỗi nhóm phải luôn cân bằng giữa những việc mà chúng ta làm nhằm cải thiện khả năng và việc lưu hành sản phẩm để đưa giá trị đến với khách hàng. Để làm việc này một cách hiệu quả, điều quan trọng là phải quản lý cả hai loại công việc ở cấp độ tổng quan và cấp độ chuỗi giá trị. Trong chương này chúng tôi mô tả biện pháp đạt được điều này bằng việc sử dụng một khuôn khổ có tên là Phương pháp Kata Cải tiến (Improvement Kata). Đây được coi là bước đầu tiên mà chúng ta phải làm để thúc đẩy sự cải thiện liên tục trong quá trình thực hiện các chương trình quy mô lớn. Sau khi đã đạt được điều này, chúng ta có thể sử dụng các công cụ trong các chương tiếp theo để xác định và gỡ bỏ những hoạt động-không-tạo-thêm-giá trị vào tiến trình phát triển sản phẩm của mình.

NGHIÊN CỨU TRƯỜNG HỢP NHÓM HP LASERJET FIRMWARE

Chúng ta sẽ bắt đầu bằng một nghiên cứu về trường hợp của HP LaserJet Firmware, một nhóm vốn từng phải đối mặt với vấn đề cả về tính gắn kết và khả năng thực thi. Như tên của nhóm đã gợi ý, đây là một nhóm làm việc về phần mềm nhúng với các khách hàng không muốn thường xuyên nhận cập nhật phần mềm. Tuy nhiên, nhóm HP LaserJet Firmware là một ví dụ tuyệt vời về cách thức mà một nhóm phân tán áp dụng hiệu quả các nguyên tắc được mô tả trong phần còn lại của Phần III và khẳng định lợi ích kinh tế xuất phát từ việc chấp nhận những nguyên tắc này.

Bộ phận LaserJet Firmware của HP đã xây dựng một chương trình cơ sở vận hành tất cả các máy quét, máy in và các trang thiết bị đa chức năng. Nhóm này bao gồm 400 người phân bổ quanh nước Mỹ, Brazil và Ấn Độ. Năm 2008, bộ phận này gặp một vấn đề: họ đang tiến triển quá chậm chạp. Họ đã đặt trên đường găng tất cả các sản phẩm mới lưu hành trong nhiều năm và không thể đem lại những tính năng mới: “Chúng ta sẽ có hàng triệu ý tưởng tiếp thị và làm cho khách hàng bối rối. Chúng ta chỉ nói với họ: ‘Hãy thoát khỏi danh sách của ông/ bà đi, hay chọn hai điều mà ông/bà muốn nhận được trong 6-12 tháng tới.’” Họ đã cố gắng đầu tư, thuê mướn và thuê ngoài để có giải pháp khắc phục vấn đề nhưng vẫn không hiệu quả. Họ cần một cách tiếp cận mới.

Bước đầu tiên của họ là hiểu được vấn đề một cách có chiều sâu hơn. Họ tiếp cận bước này bằng việc sử dụng kế toán hành động – phân bổ chi phí cho các hoạt động mà nhóm đang thực hiện. Bảng 6-1 thể hiện những gì mà họ đã khám phá được.

Bảng 6-1. Các hoạt động của nhóm Laser Jet Firmware năm 2008.

Bước đi này đã hé lộ một lượng lớn những hoạt động không-tạo- thêm-giá trị trong công việc của họ, như chuyển đổi mã giữa các nhánh và lập trước kế hoạch chi tiết. Số lượng lớn nguồn lực được sử dụng cho hỗ trợ sản phẩm hiện thời cũng cho thấy một vấn đề về chất lượng của phần mềm được sản xuất. Chi phí dành cho việc hỗ trợ này thực chất đang phục vụ cho cầu thất bại² chứ không phải cầu giá trị vốn chỉ chiếm 5% chi phí của nhóm.

Nhóm này đặt mục tiêu tăng gấp 10 lần mức chi tiêu cho đổi mới. Để đạt được mục tiêu đó, họ đưa ra một quyết định táo bạo nhưng đầy rủi ro là xây dựng một nền tảng chương trình cơ sở mới từ những gì vụn vặt hiện có. Có hai mục đích chính khi kiến tạo nền tảng “FutureSmart” mới. Mục đích thứ nhất là tăng chất lượng trong khi giảm số lượng những kiểm thử thủ công cần thiết cho việc lưu hành chương trình cơ sở mới (một chu trình kiểm thử thủ công hoàn chỉnh cần đến 6 tuần).

² Failure demand là một khái niệm được sử dụng trong các tổ chức dịch vụ có nghĩa là “nhu cầu gây ra do không thể hoặc có thể làm gì đó đúng đắn cho khách hàng”. (ND)

Nhóm hy vọng rằng có thể đạt được mục đích này qua:

◆ Việc thực hiện tích hợp liên tục (vấn đề chúng tôi mô tả trong Chương 8)

◆ Đầu tư lớn cho kiểm thử tự động

◆ Tạo một mô phỏng phần cứng để có thể thực hiện kiểm thử trên nền tảng ảo

◆ Tái hiện những kiểm thử thất bại trên hệ thống máy tính của lập trình viên

◆ Trong ba năm họ phát triển chương trình cơ sở mới, đã có hàng nghìn các cuộc kiểm thử tự động được tiến hành.

Bước thứ hai, họ muốn loại bỏ nhu cầu của nhóm trong sử dụng thời gian chuyển đổi mã giữa các nhánh (chiếm 25% tổng chi phí cho hệ thống lúc đó). Chi phí này xuất phát từ nhu cầu tạo ra một nhánh – có hiệu quả trong việc sao chép toàn bộ cơ sở mã – cho mỗi thiết bị đường dẫn mới đang được phát triển. Nếu một tính năng hoặc một hoạt động sửa lỗi được bổ sung vào một đường dẫn thiết bị là cần thiết cho các thiết bị khác, những thay đổi này sẽ cần phải được nhập (sao chép ngược lại) vào các nhánh mã tương ứng cho các thiết bị mục tiêu, như được thể hiện trong Hình 6-1. Chuyển từ phát triển dựa trên các nhánh sang phát triển dựa trên trục chính (trunk-based development³) cũng là điều cần thiết để thực hiện tích hợp liên tục. Vì vậy nhóm này quyết định tạo một nền tảng đơn lẻ với nhiều bộ phận có thể chạy trên bất kỳ thiết bị nào, từ đó làm mất nhu cầu sử dụng các nhánh kiểm soát phiên bản để kiểm soát sự khác biệt giữa các thiết bị.

³ Trunk-based development là sự phát triển một nhánh chính của mã nguồn. (ND)

Mục đích cuối cùng của nhóm là giảm lượng thời gian mà các thành viên phải sử dụng vào việc lên kế hoạch chi tiết cho các hoạt động. Các bộ phận có trách nhiệm tiếp thị các dòng sản phẩm khác nhau đã khăng khăng phải có kế hoạch chi tiết, đơn giản là vì họ không tin tưởng vào việc lưu hành sản phẩm của nhóm chương trình cơ sở.

Phần lớn lượng thời gian này được sử dụng để điều chỉnh kế hoạch chi tiết sau khi không đáp ứng được các kế hoạch ban đầu.

Hơn nữa, nhóm không biết cách thực hiện kiến trúc mới và trước đó đã không sử dụng phương pháp phát triển dựa trên nhánh chính hoặc tích hợp liên tục ở quy mô phù hợp. Họ cũng hiểu rằng việc kiểm thử tự động sẽ đòi hỏi đầu tư rất nhiều. Họ có thể tiếp tục xúc tiến công việc bằng cách nào?

Hình 6-1. Phát triển dựa trên nhiều nhánh và Phát triển dựa trên trục chính

Tất cả đều quá dễ dàng khi chuyển một chuỗi các sự kiện thành một câu chuyện trong nỗ lực giải thích kết quả – một sự thành kiến mang tính kinh nghiệm mà Nassim Taleb gọi là ngụy biện liên tưởng (narrative fallacy⁴). Người ta vẫn tranh luận việc có phải các phương pháp luận được sinh ra bằng cách này không. Những gì tác động đến chúng ta khi nghiên cứu trường hợp FutureSmart là sự tương đồng giữa phương pháp quản lý chương trình của nhóm quản lý kỹ thuật FutureSmart và cách tiếp cận mà Toyota sử dụng để quản lý đổi mới như được Mike Rother mô tả trong cuốn Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results (tạm dịch: Toyota Kata: Quản lý con người để cải tiến, thích nghi và giành được kết quả vượt trội).

⁴ Là thuyết mà người ta thường gắn một sự cố nào đó với một sự cố khác để liên tưởng với nhau. (ND)

GIẢM CHI PHÍ NHỜ LIÊN TỤC ĐỔI MỚI TIẾN TRÌNH BẰNG PHƯƠNG PHÁP KATA CẢI TIẾN

Kata Cải tiến, theo mô tả của Mike Rother, là một khuôn khổ đa năng và một bộ các biện pháp thực hành để đạt được mục đích khi mà con đường đi đến đích có nhiều bất trắc. Phương pháp này yêu cầu chúng ta phải tiến những bước tái lặp và cải tiến bằng cách thực hiện những chu trình thử nghiệm rất nhanh. Việc làm theo Kata Cải tiến cũng giúp tăng khả năng và kỹ năng của những nhân viên vì nó đòi hỏi họ phải giải quyết các vấn đề của chính mình qua một tiến trình thử nghiệm liên tục, tạo nên một bộ phận không thể tách rời của bất kỳ tổ chức học hỏi nào.

Cuối cùng, Kata Cải tiến giúp làm giảm chi phí bằng việc phát hiện và loại bỏ lãng phí trong các tiến trình.

Trước tiên, phương pháp Kata Cải tiến phải được sự chấp thuận của ban quản lý bởi vì đây là một triết lý quản lý tập trung vào việc phát triển các khả năng của những người mà họ quản lý đồng thời giúp cho tổ chức có thể đạt được mục đích trong điều kiện bất trắc. Cuối cùng, mọi người trong tổ chức cần thực hành Kata Cải tiến một cách thường xuyên để đạt được mục đích và đáp ứng các thách thức. Đây là những gì tạo ra một nền văn hóa cải tiến, thử nghiệm và đổi mới liên tục.

Để hiểu cách vận hành của phương pháp này, trước tiên chúng ta hãy nghiên cứu khái niệm kata. Một kata là “một thủ tục được thực hành một cách cẩn trọng, vì thế kết cấu của nó trở thành một thói quen.” Hãy nghĩ đến việc luyện tập âm giai (scale) để phát triển trí nhớ cơ và sự khéo léo của đôi bàn tay khi học đàn piano hoặc thực hành các cơ chế di chuyển cơ bản khi học một môn nghệ thuật quân sự (thuật ngữ kata được hình thành từ đây) hoặc một môn thể thao. Chúng ta muốn tạo thói quen liên tục cải tiến để khi phải đối mặt với một môi trường mà con đường tiến đến mục đích có nhiều bất trắc, chúng ta đã có một lộ trình định hướng thái độ của mình từ trong bản năng và vô thức.

Tại Toyota, một trong những nhiệm vụ chính của các nhà quản lý là giáo dục cơ chế Kata Cải tiến cho các nhóm của họ (trong đó có các thực tập sinh) và tạo thuận lợi cho việc thực hiện nó. Đó là một phần công việc thường nhật của họ, qua đó giúp trang bị cho các nhóm phương pháp giải quyết các vấn đề của chính họ. Điều thú vị của cách tiếp cận này là nếu mục đích hoặc môi trường của tổ chức thay đổi, chúng ta không cần phải thay đổi cách làm việc bởi vì nếu mọi người đang thực hiện Kata Cải tiến thì tổ chức đó sẽ tự động thích nghi với những điều kiện mới.

Phương pháp Kata Cải tiến có bốn giai đoạn mà chúng ta phải lặp lại trong một vòng tròn được mô tả trong Hình 6-2.

BỐN BƯỚC CẢI TIẾN CỦA MÔ HÌNH KATA CẢI TIẾN

Một mẫu hình công tác khoa học và có hệ thống

Hình 6-2. Phương pháp Kata Cải tiến (với sự cho phép của Mike Rother)

Hiểu phương hướng

Chúng ta bắt đầu bằng việc hiểu phương hướng. Phương hướng bắt nguồn từ tầm nhìn do ban lãnh đạo tổ chức đưa ra. Một tầm nhìn tốt sẽ có sức truyền cảm hứng nhưng nhiều khả năng là không thể thành hiện thực. Ví dụ, một tầm nhìn lâu dài cho các hoạt động sản xuất của Toyota là “dòng chảy một sản phẩm với chi phí thấp nhất có thể”. Trong cuốn Leading Lean Software Development (tạm dịch: Lãnh đạo phát triển phần mềm tinh gọn), Mary và Tom Poppendieck mô tả việc Paul O’Neill đặt mục tiêu cho Alcoa là “Sự an toàn hoàn hảo cho tất cả những người có liên quan đến Alcoa” khi ông trở thành CEO năm 1987.

Mọi người cần hiểu rằng họ phải luôn làm việc theo tầm nhìn đó và không bao giờ ngừng cải tiến. Chúng ta sẽ gặp những khó khăn khi hướng đến tầm nhìn đó. Bí quyết là hãy coi đây là những vật cản cần được loại bỏ thông qua quá trình thử nghiệm chứ không phải là sự phản đối thử nghiệm và thay đổi.

Dựa vào tầm nhìn của mình theo Yêu cầu Nhiệm vụ, chúng ta phải hiểu được phương hướng mà chúng ta đang theo đuổi ở cấp độ toàn tổ chức và cấp độ chuỗi giá trị. Thách thức này có thể được thể hiện dưới dạng bản đồ chuỗi giá trị thời tương lai (xem Chương 7 để tìm hiểu thêm về bản đồ chuỗi giá trị). Việc này cần tạo ra kết quả định lượng cho khách hàng và chúng ta nên xây dựng kế hoạch để đạt được điều đó trong thời gian từ 6 tháng đến 3 năm.

Lập kế hoạch: Nắm chắc tình hình hiện tại và thiết lập một điều kiện mục tiêu

Khi đã hiểu được phương hướng ở cấp độ tổ chức và chuỗi giá trị, chúng ta định hướng hoạt động của mình ở cấp độ tiến trình một cách mạnh mẽ và tái lặp không ngừng. Rother đề xuất việc thiết lập các điều kiện mục tiêu cho một đường chân trời trong khoảng từ 1 tuần đến 3 tháng, ưu tiên các đường chân trời ngắn hơn cho những người mới bắt đầu. Đối với các nhóm đang sử dụng phương pháp tái lặp và tăng cường trong phát triển sản phẩm, sẽ có ý nghĩa khi sử dụng các biên giới tái lặp (iteration hoặc sprint⁵) trong cả phát triển sản phẩm và các vòng lặp Kata Cải tiến. Còn các nhóm sử dụng các phương pháp dựa trên dòng chảy như Phương pháp Kanban (xem thêm Chương 7) và phân phối liên tục (được mô tả trong Chương 8) có thể tạo ra các vòng lặp Kata Cải tiến ở cấp độ tổng quan.

⁵ Sprint là trái tim của Scrum, tức là một khung-thời-gian (time-box) gồm 2-4 tuần để tạo ra các phần tăng trưởng của sản phẩm có thể chuyển giao được. Sprint có khoảng thời gian nhất quán trong suốt quá trình phát triển. Một Sprint mới bắt đầu ngay khi Sprint trước khép lại. Sprint chứa và bao gồm cuộc Họp Kế hoạch Sprint (Sprint Planning Meeting), các cuộc Họp Scrum hằng ngày (Daily Scrum), một buổi họp Sơ kết Sprint (Sprint Review) và một buổi họp Cải tiến Sprint (Sprint Retrospective). (ND)

Cũng như tất cả các phương pháp phát triển sản phẩm tái lặp, các vòng lặp Kata Cải tiến bao gồm một phần kế hoạch và một phần thực thi. Ở đây, nhiệm vụ của phần lập kế hoạch là nắm bắt hiện trạng ở cấp độ tiến trình và thiết lập một điều kiện mục tiêu mà chúng ta tập trung đạt được vào cuối vòng lặp tiếp theo.

Việc phân tích hiện trạng “được thực hiện nhằm tìm hiểu tình hình thực tế và những thông tin mà bạn cần để sau đó mô tả được một điều kiện mục tiêu phù hợp tiếp theo. Những gì bạn đang cố gắng làm là tìm ra kết cấu vận hành hiện tại để có thể thiết lập một kết cấu hoạt động mong muốn, tức là một điều kiện mục tiêu.” Điều kiện mục tiêu “mô tả bằng các chi tiết mang tính định lượng về cách mà bạn muốn một tiến trình hoạt động... Đó là sự mô tả và cụ thể hóa kết cấu vận hành mà bạn muốn một tiến trình hay một hệ thống sẽ có vào một thời điểm nào đó trong tương lai.”

Nhóm làm việc sẽ nắm bắt tình hình hiện tại, đồng thời thiết lập một điều kiện mục tiêu. Tuy nhiên, trong giai đoạn lập kế hoạch, nhóm không vạch ra cách tịnh tiến đến điều kiện mục tiêu. Theo Kata Cải tiến, mọi người làm việc và cố gắng đạt được điều kiện mục tiêu bằng cách thực hiện hàng loạt các cuộc thử nghiệm chứ không phải là theo một kế hoạch.

Một điều kiện mục tiêu xác định tiến trình đang thực hiện, đặt mốc thời gian cần giành được một điều kiện cụ thể và cụ thể hóa các chi tiết mang tính định lượng của tiến trình theo cách mà chúng ta muốn nó tồn tại. Ví dụ về các điều kiện mục tiêu bao gồm các giới hạn đang hình thành, việc thực thi Kanban hay một tiến trình tích hợp liên tục, số lượng những kết quả tốt đẹp mà chúng ta mong muốn nhận được mỗi ngày.

Tiến đến điều kiện mục tiêu

Do thực hiện đổi mới tiến trình trong điều kiện bất trắc, chúng ta không thể biết trước cách đạt được điều kiện mục tiêu. Điều này tùy thuộc vào các nhân viên đang làm việc với hàng loạt các thử nghiệm sử dụng vòng Deming (lập kế hoạch, tiến hành, kiểm tra, hành động), như được mô tả trong Chương 3. Những sai lầm chính mà mọi người thường mắc phải khi theo vòng Deming là thực hiện nó quá thưa thớt và mất quá nhiều thời gian mới hoàn thành một vòng. Với Kata Cải tiến, mọi người cần thực hiện các thử nghiệm hằng ngày.

Mỗi ngày, mọi thành viên của nhóm cần trả lời 5 câu hỏi:

1. Điều kiện mục tiêu là gì?

2. Tình hình thực tế hiện nay là gì?

3. Những trở ngại nào mà bạn cho là đang ngăn bạn không đạt được điều kiện mục tiêu? Bạn đang giải quyết những trở ngại nào lúc này?

4. Bước tiếp theo của bạn là gì? (Bắt đầu vòng PDCA). Bạn mong đợi điều gì?

5. Khi nào ta có thể bắt đầu đi và xem ta học được gì từ những bước đi đó?

Khi không ngừng tái lặp vòng tròn đó, chúng ta sẽ đi đến bước cuối cùng để đạt đến sự cải tiến. Chúng ta chờ đợi điều gì? Điều gì đã thực sự xảy ra? Chúng ta học được gì? Với cùng một trở ngại, chúng ta có thể giải quyết trong thời gian vài ngày.

Cách tiếp cận thử nghiệm đã trở thành phương pháp làm việc trung tâm của các kỹ sư và nhà thiết kế. Các nhà thiết kế, những người sáng tạo và kiểm thử các nguyên mẫu để giảm thời gian mà một người dùng cần sử dụng để hoàn thành một nhiệm vụ, thực sự say sưa với tiến trình này. Đối với các nhà phát triển phần mềm sử dụng phương pháp phát triển dựa trên kiểm thử, mỗi dòng mã vận hành mà họ viết ra đều là một phần quan trọng của một thử nghiệm cần phải thực hiện và tạo ra một cơ chế kiểm thử đơn vị (unit test⁶). Đây là một bước trên con đường mà một chương trình thực hiện cải tiến giá trị, điều có thể được cụ thể hóa thành dạng một điều kiện mục tiêu như chúng ta mô tả trong Chương 9.

⁶ Unit Test là kỹ thuật kiểm nghiệm các hoạt động của mọi chi tiết mã (code) với một quy trình tách biệt với quy trình phát triển phần mềm, giúp phát hiện sai sót kịp thời. UT còn có thể giúp phát hiện các vấn đề tiềm ẩn và các lỗi thời gian thực trước khi chuyên viên kiểm định chất lượng (QA – Quality Assurance) tìm ra, thậm chí có thể sửa lỗi ngay từ ý tưởng thiết kế. (ND)

Kata Cải tiến đơn giản là một sự khái quát hóa cách tiếp cận cải tiến này, kết hợp với việc áp dụng nó ở nhiều cấp độ khác nhau của tổ chức như chúng ta sẽ thảo luận khi trình bày về việc triển khai chiến lược trong Chương 15.

Sự khác biệt giữa Kata Cải tiến và các phương pháp khác

Bạn có thể nghĩ rằng Kata Cải tiến là một siêu phương pháp bởi vì nó không áp dụng cho một lĩnh vực cụ thể nào mà cũng chẳng cho bạn biết phải làm điều gì. Nó không phải là một cuốn sách giải trí mà, cũng như Phương pháp Kanban, nó dạy các nhóm cách phát triển cuốn sách giải trí mà họ đang có. Theo nghĩa này, nó khác với các khuôn khổ và phương pháp linh hoạt khác. Với Kata Cải tiến, không cần phải làm cho các tiến trình hiện có phù hợp với những việc cụ thể trong khuôn khổ của nó; mà tiến trình và các biện pháp bạn sử dụng được kỳ vọng là sẽ hình thành theo thời gian. Đây là đặc tính cốt lõi của tính linh hoạt: các nhóm không thể trở nên linh hoạt nếu chấp nhận một phương pháp. Thay vào đó, tính linh hoạt thực sự có nghĩa là các nhóm không ngừng làm việc để phát triển các tiến trình nhằm giải quyết những trở ngại cụ thể mà họ phải đối mặt ở bất kỳ thời điểm nào.

LƯU Ý

Học hỏi vòng lặp đơn và học hỏi vòng lặp kép

Thay đổi cách tư duy và ứng xử khi phản ứng với một thất bại là điều quan trọng để học hỏi hiệu quả. Đây là những gì phân biệt việc học hỏi vòng lặp đơn và học hỏi vòng lặp kép (xem Hình 6-3). Triết gia quản trị Chris Argyris là người giới thiệu các thuật ngữ này. Ông tóm tắt chúng như sau: “Khi một lỗi được phát hiện và sửa sai cho phép tổ chức tiếp tục các chính sách hiện tại và đạt được các mục tiêu hiện tại thì tiến trình sai-và-sửa đó là học hỏi vòng lặp đơn. Học hỏi vòng lặp đơn giống như một chiếc máy điều hòa nhận biết được khi nào thì trời quá nóng hoặc quá lạnh và sẽ tắt hoặc bật chức năng sưởi. Chiếc điều hòa đó có thể thực hiện chức năng này vì nó có thể nhận được thông tin (về nhiệt độ phòng) và tiến hành điều chỉnh nó. Học hỏi vòng lặp kép xảy ra khi lỗi đó được phát hiện và sửa sai bằng những biện pháp liên quan đến việc điều chỉnh các quy định, chính sách và mục tiêu cơ bản của một tổ chức.”Argyris lập luận rằng rào cản chính cho học hỏi vòng lặp kép là thái độ phòng thủ khi đối mặt với bằng chứng rằng chúng ta cần phải thay đổi tư duy, điều có thể xảy ra ở cả cấp độ cá nhân và tổ chức. Chúng ta sẽ thảo luận cách vượt qua sự lo lắng và tính phòng thủ này trong Chương 11.

Khi bạn thực hành Kata Cải tiến, việc cải thiện tiến trình trở thành một công việc có kế hoạch, tương tự với việc tạo ra gia số sản phẩm. Điều then chốt là chúng ta không lên kế hoạch về biện pháp để giành được điều kiện mục tiêu, cũng như tạo ra các sự kiện, tính năng, các phần việc hay nhiệm vụ. Trên thực tế, các nhóm làm điều này thông qua việc thử nghiệm trong tiến trình của một vòng lặp.

Hình 6-3. Học hỏi vòng lặp đơn và học hỏi vòng lặp kép

TRIỂN KHAI KATA CẢI TIẾN

Sự nghiệp của Rother trong Kata Cải tiến là kết quả trực tiếp từ việc ông nghiên cứu cách trở thành nhà quản lý tại Toyota. Không có chương trình huấn luyện chính thức, cũng không có bất kỳ sự hướng dẫn rõ ràng nào. Tuy nhiên, để trở thành một nhà quản lý ở Toyota, trước tiên người ta phải làm việc ở quầy hàng, qua đó tham gia vào tiến trình Kata Cải tiến. Nhờ vậy, họ được huấn luyện một cách gián tiếp về phương pháp quản lý tại Toyota.

Cách thức này là một vấn đề cho những người muốn học cách quản lý theo cách này hoặc muốn tiếp nhận cơ chế Kata Cải tiến. Đó cũng là một vấn đề cho Toyota, một tổ chức muốn phát triển nhanh hơn mức có thể thông qua một mô hình thực tập hiệu quả cho các nhà quản lý.

Vì vậy, Rother giới thiệu Huấn luyện Kata để bổ sung cho Kata Cải tiến. Đó là một phần của việc triển khai Kata Cải tiến, nhưng cũng là cách để hỗ trợ mọi người khả năng làm việc với Kata Cải tiến, bao gồm cả các nhà quản lý.

Rother hướng dẫn triển khai Kata Cải tiến trong cuốn The Improvement Kata Handbook (tạm dịch: Sổ tay Kata Cải tiến) hiện có trên trang web của ông tại địa chỉ http://bit.ly/11iBzIY.

NHÓM HP LASERJET ĐÃ THỰC HÀNH KATA CẢI TIẾN NHƯ THẾ NÀO?

Phương hướng mà ban lãnh đạo HP LaserJet đưa ra là cải tiến năng suất gấp 10 lần nhằm đưa chương trình cơ sở ra khỏi đường găng, qua đó phát triển sản xuất và giảm chi phí. Họ có ba mục tiêu quan trọng:

1. Tạo một nền tảng duy nhất để hỗ trợ tất cả các thiết bị

2. Tăng chất lượng và giảm số lỗi cần phải sửa trước khi ra mắt sản phẩm

3. Giảm thời gian dành cho việc lập kế hoạch

Họ không biết chi tiết về con đường để đạt được những mục đích này và không cố gắng định hình nó. Quyết định chính là phải thực hiện các vòng lặp và đặt ra các điều kiện mục tiêu cần đạt được vào cuối mỗi vòng lặp kéo dài 4 tuần. Các điều kiện mục tiêu cho Vòng lặp 30 (khoảng 2,5 năm sau khi bắt đầu nền tảng FutureSmart) được thể hiện trong Hình 6-4.

Việc đầu tiên cần chú ý là các điều kiện mục tiêu (hoặc “tiêu chuẩn exit”; như đề cập trong FutureSmart) đều phải là các điều kiện có thể định lượng được. Thực tế là chúng cần đạt tất cả các thành tố của các mục tiêu SMART: Cụ thể (Specific), có thể định lượng (Measurable), khả quan (Achievable), phù hợp (Relevant) và đúng hạn (Time bound) (tiêu chuẩn cuối là ưu điểm vượt trội của tiến trình tái lặp). Hơn nữa, nhiều điều kiện mục tiêu không chú trọng đem đến các tính năng mà quan tâm đến các thuộc tính của hệ thống, ví dụ như chất lượng, và đến các hoạt động được thiết kế để thẩm định những thuộc tính này, như là kiểm thử tự động. Vì vậy, các mục tiêu cho toàn bộ chương trình phân bổ cho 400 người trong vòng một tháng được bao quát ngắn gọn chỉ trong một mặt giấy – tương tự như biện pháp tiêu chuẩn A3 được sử dụng trong Hệ thống Sản xuất Toyota.

Các điều kiện mục tiêu được lựa chọn như thế nào? Chúng là “những mục đích mạnh mẽ mà nhóm cảm thấy khả thi, quan trọng và phải đạt được trong 4 tuần... Về cơ bản, chúng ta nỗ lực rất vất vả nhằm đạt được những mục tiêu dàn trải này nhưng thường kết thúc khi chỉ đạt khoảng 80% những gì mà ta cho là mình có thể làm được vào đầu tháng.” Thông thường, các điều kiện mục tiêu sẽ được thay đổi hoặc thậm chí phải từ bỏ nếu nhóm nhận thấy rằng các nỗ lực đạt được chúng gây ra những hậu quả không mong muốn: “Bạn sẽ ngạc nhiên với những gì học hỏi được trong một tháng và bạn phải điều chỉnh dựa trên tiến trình khám phá trong quá trình phát triển.”

Hình 6-4. Những điều kiện mục tiêu cho vòng lặp 30

Điều gì xảy ra khi chúng ta không đạt được các điều kiện mục tiêu?

Trong những nền văn hóa tổ chức áp chế hoặc quan liêu, không đạt được 100% các điều kiện mục tiêu cụ thể về cơ bản bị coi là thất bại. Tuy nhiên, trong nền văn hóa giàu sinh lực, chúng ta không kỳ vọng có thể đạt được tất cả các điều kiện mục tiêu. Mục đích của việc đặt ra các điều kiện mục tiêu mạnh mẽ là để bộc lộ những trở ngại để tìm cách vượt qua trong quá trình cải tiến sâu sắc hơn. Mỗi vòng lặp cần kết thúc bằng việc tổng kết (được mô tả trong Chương 11), trong đó chúng ta tìm ra biện pháp để tiến bộ hơn. Kết quả của những hoạt động đó trở thành một phần đầu vào cho các điều kiện mục tiêu của các vòng lặp tiếp theo. Ví dụ, nếu trong ngày không đạt một điều kiện mục tiêu về số hàng hóa do hệ thống sản xuất, chúng ta có thể nhận ra rằng vấn đề nằm ở chỗ ta mất quá nhiều thời gian để chuẩn bị cho các môi trường kiểm thử. Sau đó, chúng ta có thể lập một điều kiện mục tiêu là giảm thời lượng này trong vòng lặp tiếp theo.

Cách tiếp cận này là một sợi chỉ xuyên suốt cả quá trình Tư duy Tinh gọn. Phụ đề của cuốn Leading Lean Software Development (tạm dịch: Lãnh đạo phát triển Phần mềm Tinh gọn) của Mary và Tom Poppendieck viết: “Kết quả không phải là trọng tâm.” Đây là một tuyên bố mạnh mẽ chạm đến điểm chủ chốt của quan điểm tinh gọn. Nếu đạt được kết quả bằng cách bỏ qua tiến trình, chúng ta không học được cách cải thiện tiến trình. Nếu không cải thiện tiến trình, chúng ta không thể tiếp tục giành được những kết quả tốt hơn. Các tổ chức đưa vào áp dụng những tiến trình không thể thay đổi mà mọi người buộc phải theo, nhưng lại né tránh một tình huống khủng hoảng, thì sẽ thất bại trong cả hai khía cạnh trên.

Cách tiếp cận thích ứng và tái lặp này không có gì mới. Thực tế nó rất tương đồng với những gì mà Tom Gilb đề xuất trong tác phẩm năm 1988 của ông về Principles of Software Engineering Management (tạm dịch Nguyên tắc của Quản lý Kỹ thuật Phần mềm) như sau:

Chúng ta phải đặt ra các mục tiêu có thể định lượng được cho mỗi bước thực hiện nhỏ tiếp theo. Ngay cả những điều này cũng phải được bổ sung liên tục trong quá trình chúng ta học hỏi qua thực tiễn. Đó không chỉ đơn giản là việc đặt ra một bộ các mục tiêu chất lượng, nguồn lực và chức năng đầy hoài bão, và chắc chắn sẽ đáp ứng kế hoạch đặt ra. Chúng ta phải chuẩn bị sẵn sàng cho việc thương lượng và thỏa hiệp. Sau đó, phải thiết kế các giải pháp kỹ thuật trực tiếp, xây dựng nó, kiểm thử nó, lưu hành nó – và tiếp nhận các phản hồi.

Những phản hồi này phải được sử dụng để bổ sung cho thiết kế trực tiếp (nếu cần), bổ sung các ý tưởng kiến trúc lớn (nếu cần), và điều chỉnh cả mục tiêu ngắn hạn và dài hạn (nếu cần).

THIẾT KẾ ĐỂ PHÁT TRIỂN TÁI LẶP

Trong các chương trình lớn, việc thể hiện sự cải tiến trong một vòng lặp đòi hỏi phải khéo léo và kỷ luật. Thông thường, chúng ta sẽ thấy không thể chứng tỏ sự tiến bộ đáng kể của mình trong vòng từ 2-4 tuần. Hãy luôn cố gắng tìm kiếm điều gì đó, dù nhỏ, để giải quyết và đạt được một sự cải tiến nhỏ thay vì cố gắng làm điều mà bạn nghĩ là sẽ có tác động lớn hơn nhưng lại mất thời gian hơn.

Đây dĩ nhiên không phải là một ý tưởng mới. Các nhóm lớn đã làm theo cách này hàng thập kỷ rồi. Một ví dụ rõ rệt là dự án Apple Macintosh, trong đó một nhóm khoảng 100 người – cùng làm việc trong một tòa nhà duy nhất – đã thiết kế phần cứng, hệ thống vận hành và các ứng dụng cho những gì mà sau đó đã trở thành sản phẩm đột phá của Apple.

Nhóm này thường xuyên tích hợp phần cứng, hệ thống vận hành và phần mềm để chứng tỏ sự tiến bộ. Nhà thiết kế phần cứng Burrell Smith đã thuê những vi mạch lô-gic có thể lập trình để làm mẫu cho những cách tiếp cận khác nhau đối với thiết kế phần cứng một cách nhanh chóng trong tiến trình phát triển hệ thống, trì hoãn điểm bắt buộc hệ thống phải trở thành cố định – một ví dụ tuyệt vời về việc sử dụng khả năng chọn lựa để trì hoãn việc đưa ra những quyết định cuối cùng.

Sau hai năm phát triển, nền tảng chương trình cơ sở mới FutureSmart được khởi động. Kết quả là HP đã phát triển một loạt các tiến trình và công cụ làm giảm đáng kể chi phí cho những hoạt động không-tạo-thêm-giá-trị trong tiến trình phát hành sản phẩm trong khi lại tăng đáng kể sản lượng. Nhóm này có khả năng “tung sản phẩm ra thị trường một cách không bất ngờ, thường xuyên và đúng lúc”. Lần đầu tiên trong 20 năm, chương trình cơ sở xác định bỏ việc lưu hành sản phẩm mới ra khỏi đường găng. Điều này đã giúp họ có thể xây dựng sự tin tưởng của bộ phận tiếp thị sản phẩm.

Nhờ mối quan hệ mới giữa bộ phận tiếp thị sản phẩm và bộ phận chương trình cơ sở, nhóm FutureSmart có thể giảm đáng kể thời lượng sử dụng vào việc lập kế hoạch. Thay vì “cam kết đạt được toàn bộ danh sách các tính năng trước 12 tháng, điều mà chúng ta có thể không bao giờ hoàn thành đúng hạn do tất cả những thay đổi trong kế hoạch theo thời gian,” cứ 6 tháng một lần, họ đánh giá từng sáng kiến được thực hiện theo kế hoạch và dành 10 phút để tính toán thời lượng (theo tháng) dành để thực hiện các nỗ lực kỹ thuật cần thiết cho một sáng kiến xác định. Những phân tích chi tiết hơn sẽ được thực hiện khi công việc đã được lập trình thành một vòng lặp hoặc những mốc thời gian nhỏ. Một ví dụ về kết quả của một sự vận dụng này được thể hiện trong Hình 6-5.

Hình 6-5. Đánh giá của Ballpark về các sáng kiến tiếp theo

Cách làm này khác biệt lớn với cách thức hoạch định và đánh giá công việc trong các dự án lớn, nơi thường vạch ra những nội dung chi tiết về hoạt động chức năng và kiến trúc, những hoạt động này sau đó lại phải bị chia nhỏ thành những phần việc ngày càng nhỏ hơn, được phân tích một cách chi tiết, được đánh giá và đưa vào danh sách công việc tồn đọng cần được ưu tiên trước khi chúng được chấp thuận tham gia vào tiến trình phát triển.

Cuối cùng, cuộc kiểm thử quan trọng nhất trong tiến trình lập kế hoạch là liệu chúng ta có thể giữ những cam kết đã đưa ra cho các bên liên quan, trong đó có những người dùng cuối, hay không. Như chúng ta thấy, một tiến trình lập kế hoạch nhẹ nhàng hơn sẽ giúp đưa việc phát triển chương trình cơ sở ra khỏi đường găng, đồng thời giảm chi phí phát triển và khả năng thất bại. Do chúng ta biết rằng cầu thất bại sẽ tăng khi lượng đầu vào tăng, nên điều này càng gây ấn tượng nhiều hơn.

Ba năm sau khi đưa ra các đánh giá ban đầu, hoạt động vận dụng kế toán-hoạt động lần thứ hai đã đánh giá nhanh về kết quả mà nhóm FutureSmart đạt được với cách tiếp cận của họ như thể hiện trong Bảng 6-2 dưới đây.

Bảng 6-2. Hoạt động của Nhóm Chương trình cơ sở HP LaserJet năm 2011

Nhìn chung, bộ phận HP LaserJet Firmware thay đổi học thuyết kinh tế về tiến trình phân phối phần mềm bằng cách tiếp nhận phương pháp phân phối liên tục, kiểm thử tự động toàn diện, tái lặp và thích ứng trong quản lý chương trình, và một tiến trình lập kế hoạch linh hoạt hơn.

NHỮNG LỢI ÍCH KINH TẾ TỪ QUÁ TRÌNH CHUYỂN ĐỔI LINH HOẠT CỦA HP FUTURESMART

• Chi phí phát triển chung giảm xuống còn ~40%.

• Các chương trình đang được phát triển tăng ~140%.

• Chi phí phát triển trên các chương trình giảm 78%

• Các nguồn lực thúc đẩy đổi mới tăng gấp 8 lần.

Điểm quan trọng nhất cần nhớ từ trường hợp nghiên cứu này là khoản tiết kiệm chi phí khổng lồ và cải tiến sản xuất mạnh mẽ chỉ khả thi trên nền tảng có sự đầu tư lớn và liên tục của nhóm vào kiểm thử tự động và tích hợp liên tục. Ngay cả ngày nay, nhiều người vẫn nghĩ rằng Tinh gọn là một hoạt động định hướng quản lý và chỉ đơn giản là giảm chi phí. Trên thực tế, nó đòi hỏi đầu tư vào việc xóa bỏ lãng phí và giảm cầu thất bại – đó là một hoạt động định hướng công nhân mà cuối cùng, có thể không ngừng giảm chi phí, cải thiện chất lượng và năng suất.

QUẢN LÝ CẦU

Cho đến nay, chúng ta đã thảo luận cách cải thiện nguồn đầu vào và chất lượng của tiến trình phân phối sản phẩm. Tuy nhiên, chính các yêu cầu kinh doanh, ví dụ như việc phát triển các tính năng mới, lại thường làm cho loại công việc cải tiến này trở nên cần thiết hơn. Đây là một nghịch lý vì mục đích chung của tiến trình cải tiến là nhằm tăng khả năng phân phối cũng như chất lượng của những sản phẩm sẽ được lưu hành. Thường thì khó mà có thể làm rõ được kết quả của việc cải tiến. Đó là lý do tại sao điều quan trọng là phải làm cho nó hữu hình bằng cách sử dụng kế toán hoạt động, trong đó có việc đánh giá thời gian vòng đời và thời lượng được sử dụng để làm lại các hoạt động cầu thất bại.

Giải pháp là sử dụng cơ chế tương tự để quản lý cả nhu cầu và hoạt động cải tiến. Một trong những lợi ích của việc áp dụng cách tiếp cận Kata Cải tiến là tạo ra sự liên hệ với những kết quả mà chúng ta muốn đạt được trong vòng lặp tiếp theo của toàn bộ chương trình. Trong Kata Cải tiến nguyên thủy, các điều kiện mục tiêu được gắn với cải thiện tiến trình nhưng chúng ta cũng có thể sử dụng chúng để quản lý cầu.

Có hai cách để làm việc này. Trong các tổ chức có văn hóa giàu sinh lực (xem Chương 1), chúng ta có thể chỉ đơn giản là cụ thể hóa các mục tiêu kinh doanh mong muốn thành các điều kiện mục tiêu, để cho các nhóm tìm kiếm ý tưởng về tính năng và thực hiện các thử nghiệm để đánh giá xem liệu chúng có đem lại kết quả mong đợi hay không. Chúng tôi mô tả cách sử dụng đồ họa tác động và phát triển dựa trên giả thiết để đạt được điều này trong Chương 9. Tuy nhiên, trong nhiều doanh nghiệp truyền thống, về cơ bản đều có một lượng ùn ứ các công việc được ưu tiên ở cấp độ tổng quan trên cơ sở định hướng kinh doanh của doanh nghiệp hoặc do các ông chủ quyết định.

Chúng ta có thể xem xét một vài cách tiếp cận khác nhau để tích hợp một công việc còn tồn đọng với Kata Cải tiến. Một khả năng là cho các nhóm tham gia vào chương trình triển khai Phương pháp Kanban như được mô tả trong Chương 7. Điều này bao gồm việc chỉ rõ các giới hạn của công việc trong tiến trình (WIP) thuộc thẩm quyền và đặt dưới sự quản lý của các nhóm này. Các công việc mới sẽ chỉ được chấp thuận khi các công việc hiện tại được hoàn thành (“hoàn thành” với nghĩa là ít nhất đã được tích hợp, kiểm thử đầy đủ với tất cả các cuộc kiểm thử tự động và chứng tỏ là khả thi).

BÍ QUYẾT

Quản lý các công việc chồng chéo

Triển khai thực hiện một vài tính năng trong một chương trình sẽ buộc nhiều nhóm phải làm việc cùng nhau. Để đạt được điều này, bộ phận HP FutureSmart sẽ thiết lập một nhóm tính năng “ảo” nhỏ và tạm thời với nhiệm vụ là điều phối công việc giữa các nhóm liên quan.

Với một số nhóm áp dụng Scrum, Chương trình HP FutureSmart đã áp dụng cách tiếp cận cụ thể hóa một vận tốc mục tiêu (target volocity) ở cấp độ tổng quan. Những công việc phục vụ cho vận tốc mục tiêu được chấp nhận trong mỗi vòng lặp, tương đương với một giới hạn WIP. Để thực hiện cách tiếp cận này, tất cả các công việc được phân tích và đánh giá ở cấp cao trước khi được chấp thuận. Các phân tích và đánh giá đó được giữ ở mức cần thiết tối thiểu để có thể không ngừng đáp ứng các điều kiện mục tiêu tổng quát ở cấp độ tổng quan như được thể hiện trong Hình 6-5.

CẢNH BÁO

Không áp dụng vận tốc nhóm bên ngoài các nhóm

Quan trọng là bạn phải lưu ý rằng việc cụ thể hóa một vận tốc mục tiêu ở cấp độ tổng quan không buộc chúng ta phải cố gắng đánh giá hoặc quản lý vận tốc ở cấp độ nhóm hay các nhóm buộc phải áp dụng Scrum. Vận tốc ở cấp độ tổng quan cụ thể hóa khả năng làm việc được kỳ vọng của tất cả các nhóm dựa trên các đánh giá từ cấp cao như được thể hiện trong Hình 6-5. Nếu một nhóm áp dụng Scrum chấp nhận công việc dựa trên hoạt động cụ thể hóa những tính năng này, thì họ xác định các nội dung công việc ở cấp thấp hơn để triển khai thực hiện.

Tiêu chí vận tốc cấp độ nhóm của Scrum không phải là điều có ý nghĩa bên ngoài bối cảnh của một nhóm cụ thể. Các nhà quản lý không bao giờ nên cố gắng so sánh vận tốc của các nhóm khác nhau hay tập hợp các ước đoán trong toàn nhóm. Không may là chúng ta đã chứng kiến vận tốc được sử dụng làm tiêu chí để so sách năng suất giữa các nhóm. Điều đó hoàn toàn không đúng. Vận tốc không bao giờ được thiết kế hay thích hợp để trở thành một tiêu chí như vậy. Cách tiếp cận đó có thể khiến các nhóm “làm trò” với các con số và thậm chí là ngừng phối hợp hiệu quả với nhau. Trong bất kỳ trường hợp nào, không quan trọng là chúng ta đã hoàn thành bao nhiêu phần việc nếu chúng ta không đạt được kết quả kinh doanh đã đặt ra dưới dạng các điều kiện mục tiêu ở cấp độ tổng quan.

Trong chương này và chương sau, chúng tôi mô tả một biện pháp hữu hiệu hơn nhiều để đánh giá mức tiến bộ và để quản lý sản xuất. Biện pháp này không đòi hỏi tất cả các nhóm phải sử dụng Scrum hoặc “tiêu chuẩn hóa” các ước đoán hay vận tốc. Chúng tôi sử dụng kế toán hoạt động và bản đồ chuỗi giá trị (được mô tả trong Chương 7) để đánh giá năng suất, và chúng tôi sử dụng bản đồ chuỗi giá trị kết hợp với Kata Cải tiến để tăng năng suất, chủ yếu là ở cấp độ chuỗi giá trị chứ không phải cấp độ các nhóm riêng lẻ. Chúng ta đánh giá và quản lý sự tiến bộ bằng việc sử dụng các điều kiện mục tiêu ở cấp độ tổng quan, và nếu cần tăng tính rõ ràng, chúng ta sẽ giảm thời lượng của các vòng lặp.

XÂY DỰNG MỘT DOANH NGHIỆP LINH HOẠT

Nhiều tổ chức tìm cách kiểm thử và tiếp nhận các phương pháp linh hoạt để cải thiện năng suất cho các nhóm của họ. Tuy nhiên, về nguồn gốc, các phương pháp linh hoạt được thiết kế cho các nhóm nhỏ liên chức năng và nhiều tổ chức đã rất khó khăn khi sử dụng các phương pháp này ở quy mô phù hợp. Một số khuôn khổ để nâng cao tính linh hoạt chỉ tập trung vào các nhóm nhỏ và sau đó bổ sung các cấu trúc để phối hợp công việc của họ ở cấp độ tổng quan và hồ sơ đầu tư.

Gary Gruver, Giám đốc Kỹ thuật cho FutureSmart, so sánh cách tiếp cận “cố gắng nâng cao tính hiệu quả cho các nhóm nhỏ linh hoạt trong một doanh nghiệp” này với cách tiếp cận của nhóm FutureSmart là “cố gắng làm cho một doanh nghiệp trở nên linh hoạt bằng cách sử dụng các nguyên tắc linh hoạt cơ bản”. Trong cách tiếp cận FutureSmart, trong khi các nhóm hoạt động trong khuôn khổ những hướng dẫn chặt chẽ về các biện pháp kỹ thuật (sẽ thảo luận chi tiết hơn trong Chương 8), người ta ít quan tâm tới việc liệu họ có, ví dụ, thực hiện Scrum ở cấp độ nhóm hay không. Thay vào đó, các nhóm có quyền tự quyết tương đối để chọn lựa và phát triển các tiến trình của riêng họ miễn là họ có thể đáp ứng các điều kiện mục tiêu ở cấp độ tổng quan cho mỗi vòng lặp.

Điều này đòi hỏi ban quản lý kỹ thuật phải có quyền tự đưa ra các mục tiêu ở cấp độ tổng quan của mình. Cụ thể là họ không phải xin phê duyệt ngân sách chi trả cho những công việc cải thiện tiến trình như kiểm thử tự động hay hoàn chỉnh chuỗi công cụ phục vụ Tích hợp liên tục. Thậm chí doanh nghiệp còn không được tham vấn về việc này. Tất cả các yêu cầu kinh doanh cũng được quản lý ở cấp độ tổng quan. Đáng chú ý, các yêu cầu tiếp thị sản phẩm luôn trải qua tiến trình ở cấp độ tổng quan mà không giao việc trực tiếp cho các nhóm.

Một suy xét quan trọng khác là cách ứng xử với các thông số của doanh nghiệp. Trong một nền văn hóa kiểm soát, các thông số và mục tiêu thường được coi là trọng tâm và không bao giờ được cập nhật khi có những thay đổi về cách mà chúng được tạo ra. Các tổ chức sáng tạo không quản lý bằng thông số và mục tiêu. Thay vào đó, ban quản lý FutureSmart “sử dụng các thông số để tìm hiểu khi nào thì cần thảo luận về những việc chưa hoàn thành”. Đây là một phần của chiến lược “Điều hành từ ngoài văn phòng” (Management by Wandering Around) do các nhà sáng lập HP là Bill Hewlett và Dave Packard khởi xướng. Khi phát hiện một vấn đề, chúng ta hỏi nhóm đó hoặc những người đang gặp khó khăn để xem chúng ta có thể giúp được gì không. Qua đó chúng ta phát hiện một cơ hội để cải tiến. Nếu mọi người bị phạt vì không đáp ứng các mục tiêu và thông số, một điều tất yếu là họ sẽ xuyên tạc công việc và thông tin để tạo cảm giác là họ đang đáp ứng được các mục tiêu. Kinh nghiệm của FutureSmart cho thấy, có những thông số thời gian thực tốt là cách tiếp cận tốt hơn so với việc chỉ dựa vào các Scrums, hoặc Scrums của các scrums, hoặc báo cáo của Văn phòng Quản lý Dự án về các cuộc họp nhằm đánh giá thực trạng tình hình.

KẾT LUẬN

Kata Cải tiến là một phương pháp gắn kết nhóm và rộng hơn là tổ chức bằng cách xác định mục đích và chia mục đích thành các kết quả (các điều kiện mục tiêu) nhỏ và tăng trưởng để thực hiện và dần đi gần đến mục đích. Kata Cải tiến không chỉ là một siêu phương pháp giúp cải tiến liên tục ở cấp độ doanh nghiệp và chương trình; mà theo Yêu cầu Nhiệm vụ, còn thúc đẩy tính sở hữu và mong muốn đạt được kết quả gần với yêu cầu của tổ chức. Như chúng tôi trình bày trong Chương 9, nó cũng có thể được sử dụng để điều hành những chương trình làm việc lớn.

Những đặc điểm chính của Kata Cải tiến là tính tái lặp và khả năng thúc đẩy cách tiếp cận thử nghiệm để giành được các điều kiện mục tiêu mong muốn. Vì vậy, nó phù hợp với việc hoạt động trong các điều kiện bất trắc. Kata Cải tiến cũng là một biện pháp hữu hiệu trong phát triển khả năng của nhân viên trong toàn doanh nghiệp để họ có thể tự tổ chức để phản ứng với những điều kiện thay đổi.

Việc nghiên cứu trường hợp FutureSmart cho thấy cách thức một nhóm lớn và phân bố rời rạc có thể áp dụng siêu phương pháp Kata Cải tiến để tăng năng suất lên 8 lần, cải thiện chất lượng và giảm đáng kể chi phí. Các tiến trình và công cụ mà nhóm sử dụng để giành được sự chuyển biến này thay đổi và phát triển đáng kể theo tiến trình dự án. Đây là đặc trưng của một tổ chức linh hoạt thực sự.

Thực hiện một tiến trình cải tiến liên tục ở cấp độ doanh nghiệp là điều kiện tiên quyết cho bất kỳ nỗ lực chuyển đổi quy mô lớn đang tiến triển nào (như là tiếp nhận cách tiếp cận linh hoạt trong phân phối phần mềm) ở quy mô phù hợp. Sự cải tiến liên tục thực sự thì sẽ không bao giờ kết thúc bởi vì, khi tổ chức và môi trường phát triển, chúng ta nhận thấy những gì tốt đẹp trong ngày hôm nay có thể sẽ không còn hiệu quả khi các điều kiện thay đổi. Các tổ chức hiệu năng cao không ngừng phát triển để thích nghi với môi trường của họ, và họ làm như vậy một cách có hệ thống mà không phải sử dụng đến quy trình mệnh lệnh và kiểm soát.

Câu hỏi dành cho độc giả:

◆ Bạn có biết tổ chức kỹ thuật của bạn đang sử dụng bao nhiêu thời gian vào các hoạt động không tạo-thêm-giá-trị và phục vụ cầu thất bại so với cầu giá trị, và đâu là nguồn lãng phí chủ yếu?

◆ Các nhóm kỹ thuật có phải xin phép để được đầu tư vào việc giảm lãng phí và giảm các hoạt động không tạo-thêm-giá-trị trên toàn bộ chuỗi giá trị như là xây dựng, kiểm thử và tự động hóa và tái cấu trúc việc triển khai hay không? Những yêu cầu như thế có bị từ chối vì những lý do như “không có ngân sách” hoặc “không có thời gian” không?

◆ Mọi người trong tổ chức có nhận biết được các kết quả ngắn hạn và dài hạn mà họ đang cố gắng đạt được không? Ai quyết định những kết quả này? Họ xác định, truyền tải, duyệt và cập nhật như thế nào?

◆ Các nhóm trong tổ chức của bạn có thường phản ánh về các tiến trình mà họ đang sử dụng và tìm cách thử nghiệm để cải thiện chúng? Đâu là các vòng phản hồi tại chỗ để xác định những ý tưởng nào là có giá trị và ý tưởng nào thì không? Họ mất bao lâu để nhận được những phản hồi này?

Chương 7Nhận biết giá trị và tăng chuỗi giá trị

Không có gì vô ích bằng việc thực hiện một cách hiệu quả những gì mà không hề đáng làm.

− PETER DRUCKER

Tiêu chí cho việc phát triển sản phẩm là khả năng không ngừng gắn các kế hoạch của chính mình với bất cứ lựa chọn kinh tế tốt nhất nào tại thời điểm đó.

− DONALD REINERTSEN & STEFAN THOMKE

Nhiều doanh nghiệp cứ mãi đắm chìm trong mênh mông những công việc quá sức mà phần lớn đều đem lại rất ít giá trị cho khách hàng. Cùng với việc cải tiến các sản phẩm hiện có và cho lưu hành những sản phẩm mới, mỗi doanh nghiệp đều có một vài sáng kiến và dự án chiến lược để triển khai vào bất kỳ thời điểm xác định nào, và các công việc không có kế hoạch thường tràn đến khiến chúng ta xao nhãng, không để ý đến việc đạt các mục đích đặt ra. Một phản ứng phổ biến khi gặp vấn đề này là cố gắng huy động (làm việc vất vả hơn), cải thiện tính hiệu quả (làm việc nhanh hơn) và giảm chi phí bằng những tiến trình quản lý lỗi thời và phản tác dụng. Tư duy Tinh gọn cung cấp một sự thay thế đúng đắn “có thể tóm lại trong năm nguyên tắc: chỉ ra giá trị chính xác bằng sản phẩm cụ thể, xác định chuỗi giá trị cho mỗi sản phẩm, làm cho giá trị liên tục được tạo ra, tạo điều kiện cho khách hàng tiếp nhận giá trị từ nhà sản xuất và theo đuổi sự hoàn hảo.”

Trong chương trước, chúng tôi đã trình bày cách thực thi một chiến lược cải tiến liên tục ở cấp độ tổng quan nhằm cải tiến năng suất, chất lượng và giảm chi phí. Trong chương này, chúng tôi sẽ giải thích cách mà công ty Maersk áp dụng năm nguyên tắc tinh gọn này nhằm giảm vòng thời gian của các tính năng mới đến hơn 50% trong khi đồng thời tăng cường chất lượng và tái đầu tư.

NGHIÊN CỨU ĐIỂN HÌNH: MAERSK

Trong cuốn Black Swan Farming using Cost of Delay (tạm dịch: Black Swan Farming sử dụng chi phí trì hoãn), Joshua J. Arnold và Ozlem Yuce thảo luận cách mà họ tìm hiểu việc giảm vòng thời gian tại Maersk Lines, công ty vận tải lớn nhất thế giới. Phòng IT của Maersk có ngân sách IT hàng năm hơn 150 triệu đô-la, với phần lớn các hoạt động phát triển là do các nhà cung cấp thuê ngoài trên toàn cầu tiến hành. Họ đối mặt với số lượng lớn các yêu cầu và thời hạn đưa ra thị trường ngắn: Năm 2010, thời gian trung bình của một tính năng là 150 ngày, với 24% các yêu cầu phải mất hơn một năm mới được lưu hành trên thị trường (từ ý tưởng đến sản xuất phần mềm). Vào thời điểm phân tích, tháng

10 năm 2010, hơn 2/3 trong số 4.674 các yêu cầu được xác định là đang được thực hiện trong trạng thái “tiền dự án”, đang đợi để được phân tích chi tiết và được cung cấp tài chính. Có trường hợp, “một tính năng chỉ mất 82 giờ để phát triển nhưng kiểm thử lại mất đến 46 tuần hoàn thành quá trình cuối-đến-cuối. Thời gian chờ đợi đã ngốn mất hơn 38 tuần trong đó,” phần lớn là trong trạng thái “tiền dự án” (Hình 7-1).

Hình 7-1. Sơ đồ chuỗi giá trị của một tính năng cụ thể được phân phối qua một hệ thống cốt lõi ở Maersk (được sự cho phép của Joshua J. Arnold và Ozlem Yuce)

Dựa vào những mong muốn về kết quả có “giá trị lớn hơn, lưu lượng nhanh hơn và chất lượng tốt hơn,” Arnold và Yuce chọn ra tám mục đích cho tất cả các nhóm:

1. Xác định các ưu tiên ban đầu nhanh hơn

2. Thay đổi ưu tiên bằng tiêu chí Chi phí Trì hoãn

3. Rút ra những yêu cầu từ Danh sách Ưu tiên Năng động

4. Giảm quy mô của các yêu cầu

5. Nhanh chóng hoàn thành việc viết mã nguồn

6. Tích cực quản lý công việc đang tiến hành

7. Tạo điều kiện gia tăng tốc độ phản hồi

8. Tạo điều kiện để dòng chảy suôn sẻ và bền vững

Trước đây, các tính năng luôn được ghép vào dự án khiến cho nhiều tính năng giá trị thấp được phân phối đồng thời với một số tính năng giá trị cao. Phương pháp HiPPO được sử dụng để quyết định những tính năng nào là có giá trị cao. Họ rất nỗ lực tìm kiếm “những ý tưởng đúng đắn” và phân tích chúng một cách chi tiết để xây dựng các dự án, xin phê duyệt và giải trình cho kinh phí sử dụng.

Arnold và Yuce thực thi một tiến trình mới để quản lý các yêu cầu. Họ xây dựng một danh sách các tính năng chưa được thực hiện – ban đầu là ở cấp độ dự án, nhưng sau đó ở cấp độ tổng quan và hồ sơ đầu tư – được gọi là Danh sách Ưu tiên Năng động. Khi các tính năng mới được đề xuất, chúng sẽ nhanh chóng được xác định mức độ cấp bách và buộc doanh nghiệp phải xem lại mức độ ưu tiên cho danh sách đó. Khi khả năng phát triển cho phép, tính năng ưu tiên cao nhất sẽ được “kéo ra” khỏi danh sách này.

Các tính năng được sắp xếp mức độ ưu tiên theo phương pháp Chi phí Trì hoãn (sẽ được mô tả ở phần sau của chương này), một phương pháp giúp quy đổi giá trị của một tính năng sang tiền bằng cách tính mức độ thiệt hại nếu tính năng đó không sẵn sàng khi chúng ta cần. Sử dụng cách tiếp cận này, chúng ta có thể quyết định tác động của thời gian đến giá trị và đưa ra quyết định về thứ tự ưu tiên trên cơ sở đánh giá khía cạnh kinh tế. Ví dụ, chi phí trì hoãn cho tính năng được thể hiện trong Hình 7-1 vào khoảng 210.000 đô-la mỗi tuần, có nghĩa là sự trì hoãn do việc để tính năng đó phải xếp hàng trong 38 tuần là 8 triệu đô-la. Dành thêm nỗ lực để tính giá trị tiền bạc là một việc quan trọng, giúp đi đến những giả định, những nhận thức chung và không phụ thuộc vào quyết định mức độ ưu tiên do nhân vật cao cấp nhất đưa ra từ chỗ ngồi trong phòng lạnh của mình.

Số liệu được sử dụng để sắp xếp mức độ ưu tiên của các tính năng chính là chi phí trì hoãn chia cho thời gian (hoặc CD3). Nó được tính bằng chi phí trì hoãn của một tính năng chia cho lượng thời gian mà chúng ta đánh giá là cần để phát triển và cho lưu hành tính năng đó. Điều này dựa trên thực tế là chúng ta đã giới hạn nhân lực và các nguồn lực sẵn sàng để hoàn thành công việc, và nếu một tính năng cụ thể mất nhiều thời gian để phát triển, nó sẽ “đẩy lui” những tính năng khác. Về lô-gic, nếu chúng ta có hai tính năng với cùng chi phí trì hoãn nhưng một tính năng mất thời gian phát triển gấp hai lần tính năng kia, chúng ta nên phát triển tính năng thứ hai trước. Một trong những ưu điểm của việc tính toán thời gian phát triển là nó khuyến khích mọi người chia công việc thành những phần việc nhỏ hơn và có giá trị hơn, qua đó làm tăng chỉ số CD3.

Áp dụng Danh sách Ưu tiên Năng động và sử dụng CD3 để lên kế hoạch làm việc đã giúp cho nhóm đạt được một số mục đích khác trong danh sách mục đích của mình như ra quyết định ưu tiên ban đầu nhanh hơn, giảm quy mô các yêu cầu, viết mã nguồn nhanh hơn và tạo dòng trôi chảy hơn. Đến tháng 7 năm 2011, thời gian xoay vòng trung bình đã giảm được khoảng 50% trên hai dịch vụ thực nghiệm (một trong những dịch vụ thực nghiệm là một hệ thống kế toán SAP tập trung). Arnold và Yice trình bày hai yếu tố giúp giảm thời gian xoay vòng: tăng tính khẩn cấp nhờ việc giải các bài toán Chi phí Trì hoãn và giảm quy mô công việc bằng cách chia công việc thành những phần nhỏ hơn để tăng CD3. Hơn nữa, sự hài lòng của khách hàng đối với các dự án thực nghiệm cũng tăng đáng kể.

Hình 7-2. CD3/tính năng (được sự cho phép của Joshua J. Arnold và Ozlem Yuce)

Có lẽ điều thú vị nhất là việc tính chi phí trì hoãn giúp làm rõ đâu là việc quan trọng nhất. Trong hai hệ thống được phân tích, sự phân bổ chi phí trì hoãn được thể hiện theo một đường cong theo quy tắc lũy thừa. Con số chi phí trì hoãn mỗi tuần đối với các tính năng trong dịch vụ thực nghiệm đó, thể hiện trong Hình 7-2, cho thấy rất rõ rằng có ba tính năng cần được ưu tiên hơn các yêu cầu khác. Những yêu cầu này vốn không được xác định là có mức ưu tiên cao nhất trước khi tính đến chi phí trì hoãn.

Nghiên cứu điển hình Maersk thể hiện tầm quan trọng của việc sử dụng cách tiếp cận dựa trên dòng chảy đối với việc phát triển sản phẩm thay vì một khối lượng lớn công việc được đưa ra trong các dự án, và tầm quan trọng của việc sử dụng phương pháp Chi phí Trì hoãn, chứ không phải bằng trực giác hay HiPPO, để đánh giá mức ưu tiên phù hợp cho công việc cần thực hiện.

GIA TĂNG DÒNG CHẢY

Như đã thảo luận trong Chương 6, chúng ta muốn cải thiện tính hiệu quả của tiến trình phân phối sản phẩm trước khi tiến hành cải tiến sự gắn kết. Tuy nhiên, nếu muốn chứng kiến sự cải tiến thực chất về hiệu quả công việc, chúng ta cần bắt đầu bằng việc lựa chọn chính xác điểm cần tập trung các nỗ lực. Chúng ta thường thấy các tổ chức lớn lãng phí rất nhiều nỗ lực để thay đổi các tiến trình và cách ứng xử vốn đã thể hiện rõ hoặc dễ thay đổi nhưng lại không giúp đáng kể việc giải quyết vấn đề chung. Chúng ta cần bắt đầu bất kỳ nỗ lực cải tiến nào bằng việc hiểu vấn đề xuất phát từ đâu và chắc chắn rằng chúng được nhận thức rõ ràng ở tất cả các cấp của tổ chức. Chỉ khi đó chúng ta mới có điều kiện phù hợp để xác định cần làm gì tiếp theo.

Sơ đồ chuỗi giá trị phát triển sản phẩm

Cách tốt nhất để hiểu được các vấn đề bắt đầu từ đâu là bằng cách thực hiện một hoạt động được gọi là vẽ sơ đồ chuỗi giá trị.1 Mọi tổ chức đều có nhiều chuỗi giá trị, được định nghĩa là dòng công việc từ một yêu cầu của khách hàng cho đến khi hoàn thành yêu cầu đó. Mỗi chuỗi giá trị sẽ giao với nhiều chức năng bên trong một tổ chức, như được thể hiện trong Hình 7-3.

1 Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là một phương pháp lập bản đồ trực quan về “con đường” sản xuất của sản phẩm (vật liệu và thông tin) từ “cửa đến cửa”, cho thấy được toàn bộ hệ thống từ khi khởi đầu để giúp nhà quản lý, kỹ sư, công nhân sản xuất, người lập chương trình, nhà cung cấp và khách hàng nhận ra sự lãng phí và xác định nguyên nhân của nó. Quá trình này bao gồm lập bản đồ “thực trạng hiện tại” tập trung vào những gì bạn muốn hay được gọi là kế hoạch chi tiết “thực trạng tương lai” có thể xem như là nền tảng cho các chiến lược cải tiến tinh gọn khác. (ND)

Hình 7-3. Các chuỗi giá trị có đường đi qua nhiều bộ phận của công ty

Khi khai thác những ý tưởng đã được thẩm định cho phần mềm, chuỗi giá trị mà chúng ta quan tâm liên quan đến phát triển sản phẩm, từ khi tiếp nhận một ý tưởng hoặc một yêu cầu về một tính năng hoặc sửa một lỗi của khách hàng cho đến khi phân phối sản phẩm đó đến người dùng. Mọi sản phẩm hoặc dịch vụ đều sẽ có chuỗi giá trị riêng.

Để bắt đầu, chúng ta lựa chọn sản phẩm hoặc dịch vụ muốn nghiên cứu, và vẽ sơ đồ chuỗi giá trị hiện có để phản ánh các điều kiện hiện tại. Để tránh mắc phải một lỗi phổ biến là cố gắng cải tiến thông qua việc tối ưu hóa cục bộ, điều quan trọng là phải tạo ra một chuỗi giá trị có vị thế tương lai thể hiện cách thức mà chúng ta muốn chuỗi giá trị đó lưu thông ở một thời điểm nào đó trong tương lai, thường là từ 1-3 năm. Điều này đại diện cho điều kiện mục tiêu của chúng ta. Khi đó, các chuỗi giá trị hiện tại và tương lai có thể được sử dụng làm cơ sở cho hoạt động cải tiến bằng cách áp dụng Kata Cải tiến theo quy mô của toàn bộ chuỗi giá trị như được thể hiện trong Hình 7-4.

BỐN BƯỚC CỦA PHƯƠNG PHÁP KATA CẢI TIẾN

Hình 7-4. Sơ đồ chuỗi giá trị trong bối cảnh Kata Cải tiến

Để vẽ được sơ đồ một chuỗi giá trị, chúng ta phải tập hợp nhân sự từ mọi bộ phận của tổ chức có liên quan đến chuỗi giá trị đó. Trường hợp thiết kế và phân phối sản phẩm có thể bao gồm bộ phận kinh doanh, tiếp thị sản phẩm, thiết kế, tài chính, phát triển, QA (kiểm định chất lượng) và thực hiện các chiến dịch. Điều rất quan trọng là nhóm đồ họa chuỗi giá trị phải bao gồm những người có thẩm quyền cho phép sự thay đổi cần thiết để đạt được chuỗi giá trị vị thế tương lai. Thông thường thì việc khuyến khích tất cả các bên liên quan cam kết dành từ 1-3 ngày để làm việc cùng nhau trong một phòng riêng vào cùng một thời điểm là phần khó nhất của tiến trình. Hãy hướng đến nhóm khả thi nhỏ nhất có khả năng thực hiện các tiêu chí này, dĩ nhiên là không nhiều hơn 10 người.

Thực hiện đồ họa chuỗi giá trị bao gồm việc xác định, trên diện rộng (Hình 7-5) nhiều khối tiến trình của việc phân phối sản phẩm. Cách mà bạn chia chuỗi giá trị thành các khối tiến trình (còn được gọi là các nhánh chuỗi giá trị) thực sự là một nghệ thuật. Chúng ta muốn có đủ chi tiết hữu dụng, nhưng không quá nhiều để trở nên phức tạp một cách không cần thiết và có thể lạc lối khi tranh luận về những chi tiết vụn vặt. Martin và Osterling gợi ý nên có từ 5-15 khối tiến trình. Đối với mỗi khối tiến trình trong chuỗi giá trị, chúng ta ghi lại hoạt động và tên của nhóm hoặc bộ phận thực hiện hoạt động đó.

Hình 7-5. Phác thảo một sơ đồ chuỗi giá trị với các khối tiến trình

Khi đã có một biểu đồ khối, chúng ta thu thập những dữ liệu cần thiết để tìm hiểu về tình trạng công việc bên trong chuỗi giá trị. Chúng ta muốn biết số người liên quan trong mỗi tiến trình và bất kỳ điều gì ngăn cản dòng chảy. Chúng ta cũng ghi lại lượng công việc trong mỗi khối tiến trình cũng như chuỗi dữ liệu đang chờ xử lý giữa các khối. Cuối cùng, chúng ta viết ra ba thông số chính: Thời lượng sản xuất, thời gian tiến trình và tỷ lệ hoàn thành và độ chính xác, như được thể hiện trong Bảng 7-1.

Bảng 7-1. Các thông số cho sơ đồ chuỗi giá trị

Khi vẽ sơ đồ một chuỗi giá trị, chúng ta luôn ghi lại trạng thái của các tiến trình tại thời điểm thực hiện việc này. Chúng ta sẽ thấy thú vị khi ghi lại các con số thể hiện một ý tưởng hoặc một trạng thái tốt nhất chứ không phải là trạng thái điển hình, trừ việc xem xét các con số hiện đang giúp mọi người đi theo đúng tiến trình. Bất cứ nơi nào có thể, nhóm cần thực sự đi tới những điểm mà công việc được hoàn thành và đề nghị những người thực hiện nó cung cấp những con số thực. Điều này giúp cho nhóm trải nghiệm những môi trường công việc khác nhau trên chuỗi giá trị.

Đầu vào của một bài thực hành sơ đồ chuỗi giá trị đơn cho một tính năng vốn trải qua một chuỗi giá trị phát triển sản phẩm tương đối thẳng được thể hiện trong Hình 7-6. Nếu nó chứng tỏ sự hữu dụng, chúng ta có thể đi vào chi tiết hơn trong mỗi giai đoạn của tiến trình và nêu những gì xảy ra khi một tiến trình không tiếp nhận đầu vào vì chưa hoàn thiện và thiếu chính xác. Điều này đặc biệt quan trọng khi tỷ lệ thời lượng sản xuất so với thời lượng tiến trình lớn hoặc khi mà tiến trình tiếp theo có tỷ lệ C/A thấp một cách bất thường.

Hình 7-6. Ví dụ về đồ họa chuỗi giá trị của một tính năng

Việc thực hiện lần đầu tiên bài thực hành này trong một tổ chức luôn có tính khai sáng. Mọi người, với mức độ khác nhau, ngạc nhiên – và thường là sốc – khi thấy cách mà các tiến trình họ không tham gia đã thực sự có hiệu quả và bị tác động bởi công việc của họ như thế nào.

Chúng tôi đã chứng kiến những cuộc tranh luận bùng phát! Kết quả là, bằng cách hình thành một ý tưởng tốt hơn về cách thức vận hành công việc trong tổ chức, sơ đồ chuỗi giá trị giúp gia tăng sự gắn kết, sự đồng cảm và nhận thức chung giữa các bên liên quan.

Có lẽ thông số giá trị nhất khi thực hiện bài thực hành này là %C/A. Người ta thường nhận thấy một lượng lớn thời gian bị lãng phí cho cầu thất bại, ví như việc làm lại: các lập trình viên phát hiện sai sót trong thiết kế, nhân viên kiểm thử được giao cho kiểu cấu trúc không thể vận hành hay triển khai, khách hàng yêu cầu thay đổi khi họ được chào hàng các tính năng, và những nhược điểm lớn hay các vấn đề về hiệu năng được phát hiện trong quá trình sản xuất hoặc do người dùng phản ánh. Những người ủng hộ cách làm này phải luôn nung nấu những câu hỏi sau để khám phá và nhận biết về những việc làm lại, ví dụ như:

◆ Chúng ta phát hiện ra các vấn đề trong thiết kế ở thời điểm nào?

◆ Điều gì xảy ra trong trường hợp này?

◆ Những ai liên quan đến bước đi đó?

◆ Việc chuyển giao diễn ra như thế nào?

◆ Ở thời điểm nào thì chúng ta phát hiện được tính năng đó có thực sự đem lại giá trị mong muốn cho khách hàng hay không?

◆ Những vấn đề về kiến trúc (như hiệu năng và an toàn) được phát hiện ở đâu?

◆ Tác động đến thời lượng sản xuất và chất lượng là gì?

Những vấn đề này cần được làm rõ trên sơ đồ chuỗi giá trị, xác xuất của chúng được ghi lại dưới dạng %C/A trong các tiến trình khám phá ra chúng và (khi có thể) tạo thành một phần của chuỗi giá trị nơi mà chúng thực sự được tạo ra.

Tổng lượng lãng phí trong một chuỗi giá trị doanh nghiệp thường rất lớn. Mặc dù mọi người có thể nhận thức bằng trực giác rằng các chuỗi giá trị doanh nghiệp là không hiệu quả, nhưng việc theo dõi toàn bộ chuỗi giá trị, từ ý tưởng cho tới kết quả khách hàng có thể đo lường được, thường cho thấy lượng lãng phí kinh ngạc. Sự lãng phí này tự thể hiện trong phần trăm thời gian không có giá trị gia tăng, trong mức độ thường xuyên mà công việc bị đình trệ trong các hàng đợi, và quan trọng là trong các số liệu %C/A – những con số cho chúng ta thấy mình đã thất bại trong xây dựng chất lượng ở điểm nào trong suốt các tiến trình trước đó.

Cuối cùng, sơ đồ chuỗi giá trị cho thấy sự dại dột khi thực hiện tối ưu hóa cục bộ. Trong hầu hết các trường hợp mà chúng tôi xem xét, việc làm cho một khối tiến trình hiệu quả hơn sẽ không tác động nhiều đến tổng thể chuỗi giá trị. Do việc làm lại và thời gian lãng phí là một vài trong số những yếu tố chính góp phần vào tổng thời gian phân phối nên việc thực hiện các tiến trình “linh hoạt” trong một bộ phận đơn lẻ (ví dụ như bộ phận phát triển) thường có ít tác dụng đối với tổng thể chuỗi giá trị cũng như kết quả khách hàng.

Trong nhiều trường hợp chúng ta cần xem xét lại toàn bộ cách tiếp cận trong phân phối giá trị bằng cách điều chỉnh toàn bộ chuỗi giá trị, bắt đầu bằng việc xác định các kết quả khách hàng và tổ chức có thể định lượng mà chúng ta mong muốn đạt được thông qua việc tái thiết kế. Để giảm thiểu sự đổ vỡ của kiểu thay đổi này, chúng ta thường giới hạn các nỗ lực vào một sản phẩm đơn hoặc một bộ tính năng trong một sản phẩm. Điều đó nhìn tổng thể sẽ có lợi nhất cho khách hàng và tổ chức.

Sau đó, chúng ta tạo ra một sơ đồ chuỗi giá trị vị thế tương lai để mô tả cách mà chúng ta muốn chuỗi giá trị đó vận hành trong tương lai. Mục đích của hoạt động thiết kế này là để cải thiện hiệu năng. Martin và Osterling định nghĩa hiệu năng tối ưu là “đem đến giá trị khách hàng sao cho tổ chức không phải gánh những chi phí không cần thiết; công việc chạy đều mà không đứt quãng; tổ chức đáp ứng tất cả các yêu cầu được xác định là của khách hàng; và các nhân viên an toàn và được tôn trọng. Nói cách khác, cần thiết kế công việc theo cách loại bỏ được những trì hoãn, giúp cải tiến chất lượng và giảm những chi phí, nỗ lực và sự thất vọng không cần thiết.”

Dĩ nhiên là không có câu trả lời đúng nào cho việc tạo ra một sơ đồ chuỗi giá trị, nhưng có một quy tắc hay, gọi là quy tắc ngón tay cái, giúp giảm đáng kể thời lượng sản xuất và cải thiện chỉ số %C/A được xoay vòng (cho thấy chúng ta đã làm tốt hơn việc cải tiến chất lượng). Điều quan trọng đối với những người tham gia bài thực hành này là phải dũng cảm và nghiên cứu sự thay đổi triệt để (kaikaku). Để giành được vị thế tương lai, chắc chắn mọi người phải học được các kỹ năng mới và thay đổi công việc họ đang thực hiện, và một vai trò của một vài người nào đó (nhưng không phải là những người đang tham gia) sẽ trở nên lỗi thời. Vì vậy, như chúng ta thảo luận trong Chương 11, điều quan trọng là phải ủng hộ việc học hỏi các kỹ năng và thái độ ứng xử mới, truyền tải rộng rãi và thường xuyên để không ai bị trừng phạt vì thực hiện cải tiến cả, nếu không chắc chắn bạn sẽ bị phản đối.

Ở giai đoạn này, đừng cố gắng suy đoán cách đạt được vị thế tương lai: hãy tập trung vào các điều kiện mục tiêu cần đạt được. Một khi các sơ đồ chuỗi giá trị vị thế hiện tại và tương lai đã sẵn sàng, chúng ta có thể sử dụng Kata Cải tiến để tiến đến vị thế tương lai. Trong Chương 6 chúng tôi đã mô tả việc sử dụng Kata Cải tiến để thúc đẩy sự cải tiến không ngừng ở cấp độ tổng quan. Các điều kiện mục tiêu cho sơ đồ chuỗi giá trị vị thế tương lai cần được đưa vào các vòng Kata Cải tiến cấp độ tổng quan. Tuy nhiên, khi các chuỗi giá trị mở rộng, vượt qua khỏi giới hạn các nhóm liên quan đến các chương trình làm việc, bao gồm các đơn vị IT và kinh doanh, thì chúng ta cũng cần thiết kế các vòng Kata Cải tiến ở cấp độ chuỗi giá trị, trong đó các lãnh đạo sẽ là người thiết lập và theo dõi các chỉ số hiệu năng chính và giám sát sự tiến bộ.

CẢNH BÁO

Các tổ chức sử dụng mô hình thác nước – được mô tả trong Hình III-1 ở đầu Phần III sẽ nhận thấy rằng các nguyên tắc được mô tả trong các chương dưới đây ngày càng khó thực hiện mà không làm thay đổi căn bản kiến trúc doanh nghiệp của họ. Phương pháp Kata Cải tiến được mô tả trong Chương 6 có thể (và nên) được thực thi ở mọi nơi vì nó hầu như không khiến chúng ta phải phỏng đoán về cấu trúc của tổ chức. Chúng tôi chỉ thảo luận cách lập bản đồ và cải tiến dòng công việc thông qua tổ chức của bạn, để giúp bạn có thể bắt đầu thay đổi ngày càng lớn hình thái tổ chức của bạn và vai trò của các nhân viên. Chương 8 thảo luận những bài thực hành kỹ thuật tinh gọn giúp phân phối nhanh hơn và có chất lượng hơn với chi phí thấp hơn. Nếu tổ chức của bạn thuê ngoài nội dung kỹ thuật phần mềm, các đối tác thuê ngoài của bạn sẽ cần thực hiện những bài thực hành này. Điều đó chắc chắn buộc các mối quan hệ của bạn phải thay đổi, trong đó có những thay đổi lớn về hợp đồng. Chương 9, khi mô tả một cách tiếp cận thử nghiệm trong phát triển sản phẩm, đòi hỏi các nhà thiết kế, các kỹ sư, nhân viên kiểm thử, các chuyên gia về cơ sở hạ tầng và nhân viên sản xuất phải phối hợp trong từng vòng lặp rất ngắn. Điều này vô cùng khó thực hiện khi bất kỳ phần nào trong những chức năng này được thuê ngoài; nó có phần dễ dàng hơn khi tất cả các nhóm đều nằm trong tổ chức, nhưng vẫn đòi hỏi mọi người phải phối hợp thật tốt.

Mọi người có thể, và nên, bắt đầu hành trình mà chúng tôi mô tả trong Phần III. Cần lưu ý: Việc thực hiện toàn bộ chương trình sẽ phá vỡ nhiều tổ chức và mất nhiều năm để đầu tư và thử nghiệm thì mới thành công. Vì vậy, đừng cố gắng triển khai gấp gáp tất cả chương trình trong toàn tổ chức – hãy sử dụng sơ đồ chuỗi giá trị và chia nhỏ các sơ đồ chuỗi giá trị vị thế tương lai thành các khối để tái lặp và không ngừng phát triển, từng chuỗi giá trị một.

Giới hạn công việc trong tiến trình

Nếu mục đích của chúng ta là gia tăng dòng công việc giá trị cao thông qua chuỗi giá trị phát triển sản phẩm thì việc vẽ sơ đồ chuỗi giá trị là bước đi quan trọng đầu tiên. Tuy nhiên, chúng ta phải tiếp tục thực hiện những bước đi khác để quản lý dòng công việc trong hệ thống để giảm thời lượng sản xuất và tăng khả năng dự báo.

Hình 7-7. Ví dụ về một bản vẽ Kanban

Trong bối cảnh phát triển sản phẩm, phương pháp Kanban cung cấp các nguyên tắc và biện pháp hỗ trợ cho mục đích này, như David J. Anderson mô tả trong cuốn Kanban: Successful Evolutionary Change for Your Technology Business (tạm dịch: Kanban: Cải tổ thành công doanh nghiệp công nghệ của bạn). Trước tiên, phải làm rõ dòng công việc thông qua chuỗi giá trị: Chúng ta thực hiện sơ đồ chuỗi giá trị vị thế hiện tại và chuyển nó thành một bản vẽ thực hoặc ảo với các cột thể hiện các khối tiến trình và các hàng giữa các khối. Sau đó, chúng ta làm một tấm thẻ cho mỗi phần công việc hiện đang chạy qua chuỗi giá trị như được thể hiện trong Hình 7-7. Những tấm thẻ này được di chuyển trên bản vẽ khi công việc tiến triển qua chuỗi giá trị.

Chúng ta có thể hình dung tính năng động của chuỗi giá trị bằng cách lập một sơ đồ dòng tích lũy thể hiện số lượng công việc trong mỗi hàng và khối tiến trình theo thời gian. Một ví dụ của sơ đồ dòng tích lũy được thể hiện trong Hình 7-8. Nó thể hiện rõ ràng mối quan hệ giữa công việc đang thực hiện và thời lượng sản xuất: khi giảm WIP, thời lượng sản xuất sẽ giảm.

Hình 7-8. Một biểu đồ dòng tích lũy

Trong nghiên cứu về trường hợp Maersk, chúng ta đã thảo luận hai cách để giảm quy mô của các nhóm công việc chạy qua chuỗi giá trị phát triển sản phẩm: đó là giảm quy mô các yêu cầu và phân các dự án thành các yêu cầu có thể được ưu tiên riêng. Giới hạn công việc đang thực hiện là một cách hiệu quả để giảm quy mô các nhóm. Do việc giảm quy mô các nhóm công việc là nhân tố quan trọng bậc nhất trong việc gia tăng dòng một cách có hệ thống và giảm tính biến thể, đồng thời có tác động hiệu quả bậc hai trong cải thiện chất lượng và gia tăng sự tin cậy giữa các bên liên quan, nên chúng ta cần theo đuổi những bài thực hành này một cách không mệt mỏi và đánh giá sự tiến bộ của mình.

Phương pháp Kanban là một phương pháp toàn diện để quản lý dòng công việc thông qua chuỗi giá trị phát triển sản phẩm bằng cách sử dụng các biện pháp sau:

◆ Hình dung dòng công việc bằng cách tạo ra một bảng biểu thể hiện công việc đang thực hiện trong chuỗi giá trị tại thời gian thực.

◆ Giới hạn công việc đang thực hiện bằng cách đặt ra các giới hạn WIP cho mỗi khối tiến trình và hàng bên trong một chuỗi giá trị, đồng thời cập nhật chúng để đổi lấy thời lượng sản xuất thay vì huy động nhân lực (mọi người bận rộn như thế nào).

◆ Xác định các lớp dịch vụ cho các loại công việc khác nhau và các tiến trình quản lý công việc nhằm đảm bảo rằng những công việc khẩn cấp hoặc nhạy cảm về thời gian được ưu tiên một cách phù hợp.

◆ Xây dựng một hệ thống kéo bằng cách thống nhất về cách đưa công việc vào mỗi khối tiến trình khi khả năng cho phép – có thể bằng cách tiến hành họp thường xuyên để các bên liên quan quyết định công việc nào cần được ưu tiên dựa trên năng lực hiện có.

◆ Thường xuyên tiến hành “tổng kết kinh nghiệm hoạt động” cho các bên liên quan trong mỗi khối tiến trình để phân tích hiệu năng làm việc của họ và cập nhật các giới hạn công việc đang thực hiện, các lớp dịch vụ và phương pháp tiếp nhận công việc.

CẢNH BÁO

Các giới hạn WIP gây khó

Một phần mục đích của việc giới hạn WIP là để làm bộc lộ các cơ hội cải tiến. Áp đặt các giới hạn WIP sẽ giúp tập trung sự chú ý vào công việc bị đóng băng và khó hoàn thành, bởi vì sự thiếu khả năng hoàn thành nó ngăn cản chúng ta tiếp nhận các công việc mới, đồng thời, có xu hướng muốn giảm các giới hạn WIP để đảm bảo “việc gì đó được hoàn thành”. Điều quan trọng là ta phải tránh được xu hướng này và thay vào đó, tìm cách giải quyết gốc rễ của vấn đề.

Phương pháp Kanban tuân thủ bốn nguyên tắc cải tiến không ngừng được đưa ra để giảm thiểu thái độ phản đối sự thay đổi:

◆ Hãy bắt đầu với những gì bạn đang làm lúc này

◆ Hãy nhất trí theo đuổi sự thay đổi tăng trưởng và dần dần

◆ Ban đầu, hãy tôn trọng vai trò, trách nhiệm và các công việc hiện tại

◆ Hãy khuyến khích các hoạt động lãnh đạo ở tất cả các cấp

Phương pháp Kanban là một công cụ mạnh mẽ để cải tiến hiệu năng và tăng chất lượng cũng như sự tin cậy ở cấp độ nhóm trong một môi trường mà cấp độ quản lý cấp cao không tiếp nhận cách tiếp cận cải tiến không ngừng. Trong tình huống như thế, chúng tôi mạnh mẽ khuyến nghị các nhóm triển khai Phương pháp Kanban như là bước đầu tiên để trở nên tốt hơn. Khi bạn đã chứng tỏ được sự tiến bộ có thể định lượng, bạn vẫn cần theo đuổi cải tiến không ngừng ở cấp độ doanh nghiệp bởi vì, trong bối cảnh doanh nghiệp điển hình, chấp nhận Kanban ở cấp độ nhóm chắc chắn sẽ chỉ dẫn đến sự cải tiến phát triển.

BÍ QUYẾT

Quản lý công việc đang thực hiện ở cấp độ doanh nghiệp

Mục đích chính của việc giới hạn WIP là để hoàn thành công việc đến một mức độ chất lượng đủ cao nhằm tăng số lượng đầu vào. Giảm thời lượng sản xuất theo cách này đòi hỏi hệ thống phải có đủ sự giảm tải để quản lý WIP một cách hiệu quả. Sự giảm tải cũng quan trọng để có thể cung cấp thời gian cho việc cải thiện tiến trình. Do các lý thuyết về quản lý của chủ nghĩa Taylor trong thế kỷ XX nhấn mạnh việc tối đa hóa việc huy động công nhân, nên điều này đòi hỏi phải có sự thay đổi lớn trong tư duy của nhiều tổ chức.

Trong các doanh nghiệp, một dấu hiệu của việc có quá nhiều WIP là số lượng người được giao nhiều hơn một dự án. Cách làm nguy hiểm này tất yếu sẽ dẫn tới thời lượng sản xuất dài hơn và chất lượng thấp hơn do họ phải thường xuyên thay đổi bối cảnh làm việc. Thay vì giao cho mọi người nhiều dự án cùng lúc, hãy lập một nhóm tập trung có khả năng hỗ trợ chuyên môn cho các nhóm có nhu cầu, nhưng đừng giao những người này cho bất kỳ nhóm nào và phải thận trọng duy trì kiểm soát việc huy động họ, tốt nhất là dưới mức 100%.

CHI PHÍ TRÌ HOÃN: MỘT KHUÔN KHỔ ĐỂ PHÂN HÓA CÁC QUYẾT ĐỊNH KINH TẾ

Một trong những rắc rối lớn nhất trong phát triển sản phẩm là đưa ra các tính năng có giá trị muộn đến mức chúng không còn có giá trị cạnh tranh nữa. Như trường hợp nghiên cứu Maersk cho thấy, một yếu tố quan trọng dẫn đến rắc rối này là tập hợp các tính năng vào dự án và chỉ có thể đem lại kết quả cho khách hàng sau nhiều tháng chờ đợi. Sơ đồ chuỗi giá trị thường thể hiện – như trong trường hợp Maersk – rằng phần nhiều thời gian chờ đợi thuộc giai đoạn phân tích, khi mà các tính năng sản phẩm tồn đọng chờ được phân tích, đánh giá, phê duyệt và ưu tiên phát triển.

Như chúng ta thấy trong Chương 4, thông tin do những hoạt động này cung cấp có giá trị rất thấp. Các khuôn khổ như là Scrum khuyến nghị ưu tiên những công việc tồn đọng bằng giá trị kinh doanh nhưng không hướng dẫn nhiều về cách thức tính toán chúng. Sắp xếp ưu tiên theo giá trị kinh doanh cũng không làm rõ được thời gian nhạy cảm của công việc. Tuy nhiên, có một khuôn khổ hiệu quả giúp đưa ra các quyết định ưu tiên sáng suốt dưới góc độ kinh tế học, đó chính là Chi phí Trì hoãn. Nhóm của Maersk đã giảm thời gian chu kỳ sản xuất các tính năng giá trị cao bằng việc kết hợp các tính năng bị tách ra khỏi các dự án và sử dụng một phương pháp đơn giản là Chi phí Trì hoãn để xác định và ưu tiên cho công việc có chi phí cơ hội cao nhất.

Để áp dụng Chi phí Trì hoãn, chúng ta bắt đầu bằng việc quyết định thông số mà chúng ta đang cố gắng tối ưu hóa trên chuỗi giá trị. Đối với các tổ chức tham gia phát triển sản phẩm, thông số ngày thường là lợi nhuận vòng đời, nhưng một công ty hậu cần thì có thể sử dụng thông số chi phí trên mỗi tấn/dặm (chi phí khi vận chuyển một tấn trên mỗi dặm). Khi được thông báo về một quyết định, chúng ta xem xét tất cả các phần việc bị ảnh hưởng bởi quyết định đó và tìm cách tối đa hóa Hệ số chính (OMTM – One Metric That Matters, xem Chương 4) trên cơ sở những lựa chọn mà chúng ta có. Để làm điều này, chúng ta phải tìm ra, đối với mỗi phần công việc, rằng điều gì xảy ra đối với thông số chủ chốt của mình khi chúng ta trì hoãn công việc đó (tức là “Chi phí trì hoãn”).

Chúng ta hãy bắt đầu với một ví dụ rất đơn giản để phác thảo sơ bộ các quy trình. Giả sử sáng thứ Hai đi làm, chúng ta có hai phần việc có thể bắt đầu. Chúng ta được đảm bảo (khá chắc chắn) rằng chúng đều có mức độ ưu tiên cao nhất. Chúng ta nên làm gì?

Chúng ta bắt đầu bằng cách tính xem sẽ thiệt hại bao nhiêu nếu không làm việc đó. Nhiệm vụ A là nâng cấp một bộ phận phần mềm cốt lõi thành một phiên bản mới hỗ trợ mã hóa dữ liệu thẻ tín dụng để đáp ứng thời hạn thực hiện, cụ thể là còn hai tuần nữa từ thời điểm hiện nay. Chúng ta sẽ bị phạt 50.000 đô-la cho mỗi ngày làm việc không thực hiện phần việc này. Chi phí cho việc này là bằng 0 cho đến thời điểm bắt đầu phải trả giá, và chi phí của việc trì hoãn công việc này là 250.000 đô-la mỗi tuần sau thời hạn đó. Nhiệm vụ A sẽ mất 2 tuần.

Nhiệm vụ B là hoàn thành một tính năng then chốt mà các khách hàng tương lai yêu cầu, điều mà chúng ta đã quảng cáo là sẽ sẵn sàng trong một tuần nữa kể từ thời điểm này. Chúng ta hy vọng sẽ đạt doanh số 100.000 đô-la mỗi tuần từ khi lưu hành tính năng mới này. Hơn nữa, một trong những đối thủ cạnh tranh ở ngay sau chúng ta, và chúng ta tin rằng họ sẽ đưa ra phiên bản phần mềm mới với tính năng này trong một tháng nữa. Nhiệm vụ B mất một tuần để hoàn thành.

Những con số thật đơn giản, và các lựa chọn của chúng ta được thể hiện trong Hình 7-9. Nếu chúng ta thực hiện Nhiệm vụ A trước, tức là trì hoãn Nhiệm vụ B 2 tuần, thì chúng ta mất 200.000 đô-la. Nếu chúng ta thực hiện Nhiệm vụ B trước, trì hoãn Nhiệm vụ A 1 tuần, thì chúng ta mất 250.000 đô-la. Vì vậy, chúng ta nên thực hiện Nhiệm vụ A trước.

Nhiệm vụ A: 2 tuần, chi phí trì hoãn 250.000 đô la/tuần

Nhiệm vụ B: 1 tuần, chi phí trì hoãn 100.000 đô la/tuần

Hình 7-9. Chúng ta xét ưu tiên cho Nhiệm vụ A và B như thế nào với biện pháp Chi phí Trì hoãn?

Chúng ta cũng có thể tính toán điều gì sẽ xảy ra nếu cố gắng và làm đồng thời cả hai nhiệm vụ. Giả định rằng chúng ta dành một nửa năng lực cho mỗi nhiệm vụ, chúng ta sẽ mất 2 tuần để hoàn thành Nhiệm vụ B và 3 tuần để hoàn thành Nhiệm vụ A. Điều đó dẫn đến tổng chi phí trì hoãn là 350.000 đô-la. Điều này cho thấy chúng ta vẫn nên thực hiện Nhiệm vụ A trước khi thực hiện Nhiệm vụ B.

BÍ QUYẾT

Sử dụng CD3 để khuyến khích những khối công việc nhỏ hơn

Khi áp dụng phương pháp CD3 như được mô tả trong trường hợp Maersk, CD3 của Nhiệm vụ A là 125.000, còn CD3 của Nhiệm vụ B là 100.000, vì vậy chúng ta thấy rằng Nhiệm vụ A có mức ưu tiên cao hơn. Giả dụ chúng ta có một sự thay thế cho Nhiệm vụ B là Nhiệm vụ C. Nhiệm vụ C sẽ cung cấp giá trị tương tự cho 80% số khách hàng mong muốn tính năng đó sẽ do Nhiệm vụ B mang lại (80.000 đô-la mỗi tuần), nhưng chúng ta tính ra rằng hoàn thành C sẽ mất một nửa thời gian của B (nửa tuần). CD3 của Nhiệm vụ C sẽ là 160.000, làm cho nó có mức ưu tiên cao hơn Nhiệm vụ A. Sử dụng CD3 một cách nhất quán đem lại một hiệu ứng quan trọng, cụ thể là nó khuyến khích chúng ta chia công việc thành những phần nhỏ hơn và có giá trị hơn.

Việc sử dụng Chi phí Trì hoãn đem lại một số tác động. Khi tính toán chi phí trì hoãn của mỗi tính năng, chúng ta không còn chỉ phụ thuộc vào một người chủ sản phẩm trong đánh giá giá trị kinh doanh của những phần việc còn tồn đọng, một biện pháp tệ hại khi phải xét mức độ ưu tiên bởi vì người này phải không ngừng tính toán lại để cân nhắc tính nhạy cảm về thời gian của giá trị kinh doanh. Thay vào đó, do năng lực còn hạn chế, chúng ta coi sắp xếp mức độ ưu tiên là việc lựa chọn đâu là những phần việc nên trì hoãn.

Khi có khả năng phát triển, nhóm sẽ đơn giản là chọn khoản có chi phí trì hoãn cao nhất ở thời điểm đó. Đây là một lợi thế quan trọng của việc sử dụng Chi phí Trì hoãn: tiếp theo Yêu cầu Nhiệm vụ, nó cho phép mọi người trong tổ chức thực hiện những quyết định kinh tế sáng suốt, rõ ràng mà không cần những cơ chế ra lệnh-và-kiểm soát như việc thực hiện tổng kết, phê duyệt và xét ưu tiên một cách nặng nề bởi nhân vật cấp cao nhất trong công ty. Chúng ta chọn ra một vài mối lo ngại có thể được giải quyết một cách độc lập ở cấp độ phù hợp của tổ chức:

1. Thông số kinh tế mà chúng ta đang cố gắng tối ưu hóa là gì? (Lưu ý Thông số chính trong Chương 4.) Trách nhiệm của ban lãnh đạo là truyền tải yêu cầu về thông số này đến mọi người trong tổ chức.

2. Tác động đối với thông số trì hoãn mỗi phần công việc này là gì? Tính toán chi phí trì hoãn này là mục đích chính của việc phân tích.

3. Chúng ta nên lập chương trình và xét ưu tiên công việc như thế nào? Điều này có thể được các nhóm quyết định một cách độc lập trên cơ sở thông tin từ điểm 1 và 2 ở trên.

Hơn nữa, Chi phí Trì hoãn cung cấp cho chúng ta lập luận kinh tế để giới hạn phần việc đang triển khai. Như trong ví dụ trên, chi phí trì hoãn việc thử tiến hành đồng thời cả A và B lớn hơn việc hoàn thành thứ tự từng nhiệm vụ một.

Dĩ nhiên ví dụ trên còn rất đơn giản. Trước tiên, chúng ta đã giả định rằng Chi phí Trì hoãn sẽ vẫn kéo dài theo thời gian. Điều này hiếm khi đúng trong đời thực. Ví dụ, chi phí trì hoãn Nhiệm vụ A tăng lên 50.000 đô-la mỗi ngày ngay sau ngày cuối cùng mà chúng ta có thể bắt đầu tăng cường công việc để hoàn thành nó đúng thời hạn theo yêu cầu của khách hàng. Nhưng đối với Nhiệm vụ B, doanh số mà chúng ta có thể đạt được chắc chắn có tính nhạy cảm về thời gian khi xét thấy các đối thủ cạnh tranh của chúng ta sẽ sớm có tính năng tương tự.

Tính nhạy cảm về thời gian của chi phí trì hoãn được xác định trong một hồ sơ khẩn. Các hồ sơ khẩn có thể được sử dụng trong thực tế cho Nhiệm vụ A và Nhiệm vụ B được thể hiện trong Hình 7-10. Chi phí Trì hoãn, nằm trên trục y, thể hiện số tiền tổn thất trên một đơn vị thời gian nếu trì hoãn công việc. Để tính toán tổng chi phí trì hoãn, chúng ta tính diện tích bôi đậm của đồ thị. Mặc dù theo lý thuyết thì có nhiều hồ sơ khẩn khả dĩ, nhưng nhìn chung hầu hết các nhiệm vụ trong một tổ chức cụ thể sẽ thích hợp với một số ít các hồ sơ tiêu chuẩn. Những hồ sơ này có thể được kết hợp vào một hệ thống Kanban bằng cách sử dụng các lớp dịch vụ.

Hình 7-10. Các hồ sơ khẩn cho Nhiệm vụ A và Nhiệm vụ B

Tác động thứ hai của Chi phí Trì hoãn mà chúng ta phải đối mặt là trong nhiều trường hợp, việc tìm ra con số chi phí trì hoãn chính xác là vô cùng khó. Để tính được số tiền này, chúng ta thường đưa ra một số giả định và xem xét nhiều yếu tố. Ví dụ, không hoàn thành Nhiệm vụ A đúng thời hạn có thể dẫn đến việc khách hàng mất niềm tin vào khả năng của chúng ta trong đảm bảo an toàn dữ liệu của họ, vì vậy có thể tác động đến doanh số trong tương lai. Điều quan trọng là phải làm cho những giả định này rõ ràng, rành mạch và được ghi lại trong quá trình thảo luận về công việc để ta có thể thẩm định chúng. Điều quan trọng nhất phải nhớ là chúng ta đang hướng đến accuracy (độ chuẩn xác), chứ không phải precision (độ chính xác) trong các đánh giá của mình.¹ Nếu tính bất trắc về chi phí trì hoãn ở mức rất cao, điều này có nghĩa là chúng ta đang trong giai đoạn “khám phá” và phải kiểm thử các giả định của mình, có lẽ sử dụng một trong những kỹ thuật như đưa một thông số then chốt vào các mô phỏng Monte Carlo hoặc kiểm thử giả thiết kinh doanh bằng các MVP (được trao đổi trong Phần II).

¹ Thuật ngữ “accuracy” (độ chuẩn xác) được dùng để chỉ mức độ khác biệt giữa các giá trị đo so với giá trị “thực” hoặc giá trị “chuẩn” dùng để tham chiếu. Như vậy, thuật ngữ độ chuẩn xác có liên quan với sai số hệ thống của hệ thống đo. Thuật ngữ “precision” (độ chính xác) được dùng để chỉ độ lặp lại của các giá trị đo trong cùng một điều kiện đo. Như vậy, độ chính xác có liên quan với mức độ phân tán của các giá trị đo. (ND)

Một trong những lợi ích chính của Chi phí Trì hoãn là thay vì tranh cãi về việc trả lời cho những câu hỏi mà chúng ta đặt ra, chúng ta có thể suy luận về những giả định mà chúng ta đưa ra trong các mô hình của mình và tập trung vào việc thẩm định chúng. Chi phí Trì hoãn giúp tạo ra một sự thay đổi văn hóa quan trọng, chuyển từ các cuộc tranh cãi mang tính chính trị xem công việc của ai là quan trọng hơn sang việc tìm kiếm và thẩm định các giả định và tác động của chúng đến các biến số kinh tế. Điều này đòi hỏi mức độ trưởng thành nhất định của tổ chức. Cũng như với tất cả những hoạt động thay đổi tiến trình, chúng tôi khuyến nghị nên sử dụng Chi phí Trì hoãn để bắt đầu với một sản phẩm mà mọi người thực sự muốn thử dùng, và cung cấp sự hỗ trợ cần thiết để kiểm thử nó.

Việc áp dụng Chi phí Trì hoãn trong toàn doanh nghiệp cho phép chúng ta phân tán tiến trình ra quyết định và kiểm soát các quyết định đó dưới góc độ kinh tế. Để làm được điều này, chúng ta phải thay đổi cách tư duy về quản lý công việc, đặc biệt là vai trò của nhóm có trách nhiệm trong việc xét ưu tiên các quyết định ở cấp độ danh mục đầu tư và chương trình (thường được gọi là văn phòng quản lý dự án, hoặc là PMO). Trong mô hình Chi phí Trì hoãn, trách nhiệm chính của nhóm này chuyển từ việc đưa ra các quyết định thực tế sang việc xây dựng và cập nhật khuôn khổ ra quyết định: làm việc với các dự án tài chính và cá nhân để tạo ra những hồ sơ và mẫu tiêu chuẩn, thu thập và phân tích dữ liệu, tìm ra chi phí trì hoãn trong toàn tổ chức, và kiến tạo vòng phản hồi để không ngừng cải tiến chất lượng của tiến trình ra quyết định. Khi đó, các quyết định thực sự có thể do chính các nhóm tại chỗ đưa ra dựa trên thông tin cập nhật về chi phí trì hoãn khi có công việc mới hoặc khi mà các giả định dựa trên các tính toán hiện tại thay đổi. Đây là một sự thay đổi lớn đòi hỏi sự hỗ trợ của ban điều hành, việc thí điểm và những cải tiến dựa trên việc học hỏi trước khi sẵn sàng được toàn bộ tổ chức chấp nhận.

Cuối cùng, có những điều mà bạn không nên làm khi áp dụng Chi phí Trì hoãn. Hãy tránh việc chỉ đơn giản là gộp chi phí trì hoãn vào các phương pháp xét ưu tiên hiện có. Mục đích của Chi phí Trì hoãn là cải thiện chất lượng yêu cầu bằng cách cho phép chúng ta xác định và tránh những công việc giá trị thấp hơn đồng thời giảm thời lượng sản xuất đối với những công việc giá trị cao. Nếu biến Chi phí Trì hoãn thành một tiến trình nặng nề bên cạnh các tiến trình hiện tại, chúng ta sẽ không đạt được mục đích đó. Chi phí Trì hoãn tạo ra lợi ích lớn nhất khi các hàng chờ lớn, nói cách khác là khi có thời lượng sản xuất dài. Đó là một biện pháp đối phó giá trị khi có quá nhiều việc phải làm trong hệ thống. Nếu bạn không có các hàng chờ lớn và quá nhiều việc thì việc sử dụng Chi phí Trì hoãn chắc chắn sẽ tạo ra rất ít giá trị chung.

Đối với các sản phẩm và dịch vụ dựa trên phần mềm thì việc áp dụng các biện pháp kỹ thuật tinh gọn có ý nghĩa quan trọng trong việc giảm tổng thời lượng sản xuất và thu thập phản hồi của khách hàng càng nhanh càng tốt trong vòng đời sản phẩm. Giải pháp cuối cùng cho việc thiếu đầu vào, và vì vậy làm giảm sản lượng – là làm giảm thời lượng sản xuất nói chung bằng cách giảm quy mô các khối, quản lý công việc trong tiến trình và giảm chi phí của việc cung cấp giá trị cho khách hàng. Xét về giá trị định lượng, không gì có thể thay thế cho việc tiếp cậnkhách hàng và tiếp nhận phản hồi thực sự của họ.

KẾT LUẬN

Trong các tổ chức hiệu năng cao, ban lãnh đạo và quản lý rất chú trọng đến giá trị mà tổ chức đem lại cho khách hàng. Làm việc một cách khoa học để hướng đến các mục đích đầy thách thức, trong đó xác định và từ bỏ hoặc tránh các hoạt động không tạo-thêm-giá-trị, là bản chất của Tư duy Tinh gọn. Điều này đòi hỏi nhiều tổ chức phải thay đổi lớn về quan điểm. Sơ đồ chuỗi giá trị là một công cụ mạnh mẽ để hình dung về công việc, để chúng ta biết các điều kiện kiện tại và kiến tạo hiểu biết chung về vị thế của chúng ta hiện nay và mục đích của chúng ta là gì. Một bản vẽ sơ đồ chuỗi giá trị hiệu quả có thể thực sự giúp mở mang tầm mắt vì cho phép các nhóm lần đầu tiên hiểu được dòng công việc vận hành trong tổ chức với mục tiêu đáp ứng nhu cầu của khách hàng, và vai trò thực sự của họ trong tiến trình đó. Sau đó, kết quả của bản vẽ sơ đồ chuỗi giá trị được sử dụng để xác định các điều kiện mục tiêu cho Kata Cải tiến (Chương 6). Đến lúc này, chúng ta có thể sử dụng Phương pháp Kanban để quản lý dòng công việc thông qua chuỗi giá trị, thiết lập và cập nhật các giới hạn WIP và các lớp dịch vụ, đồng thời tạo ra một hệ thống kéo để tăng tốc dòng công việc đó.

Cải tiến dòng công việc vận hành trong tổ chức mới là một mặt của vấn đề. Mặt khác, chúng ta phải chắc chắn rằng mình đang làm đúng việc. Chi phí Trì hoãn là cách để đo lường giá trị thời gian, cho phép các nhóm đưa ra các quyết định ưu tiên rõ ràng. Thông qua việc lượng hóa giá trị công việc đang làm, chúng ta có thể tránh được những công việc có giá trị thấp. Nếu chúng ta giới hạn công việc đang thực hiện trong chuỗi giá trị và chỉ thực hiện những nhiệm vụ có giá trị cao, chúng ta có thể giảm nhanh thời gian giới thiệu với thị trường phần công việc có giá trị cao nhất đối với khách hàng.

Câu hỏi dành cho độc giả:

◆ Nhóm hoặc tổ chức của bạn sắp xếp mức độ ưu tiên cho công việc như thế nào? Bạn sử dụng một mô hình kinh tế hay để cho các HiPPO quyết định?

◆ Bạn sẽ cố gắng thực hiện một mô hình kinh tế cho lượng công việc tồn đọng hiện nay như thế nào? Tại sao không nghiên cứu các công việc trong hàng tái lặp hiện tại và đánh giá Chi phí Trì hoãn của từng công việc đó?

◆ Thời lượng sản xuất hiện nay cần thay đổi của bạn là gì? Bạn làm thế nào để có thể giảm quy mô các khối, qua đó giảm thời lượng sản xuất?

◆ Bạn làm thế nào để khám phá tác động kinh tế của công việc bạn làm một khi nó được hoàn thành? Nhóm của bạn có chỉ tập trung vào các thông số đầu vào và đầu ra, ví dụ như vận tốc không? Làm thế nào để bạn có thể làm việc với các bộ phận tài chính, quản lý sản phẩm hay các bộ phận khác để nắm được kết quả kinh doanh và tác động chính của việc bạn làm?

◆ Bạn có gom các tính năng vào các dự án như là một phần của tiến trình lập kế hoạch và đầu tư không? Bạn làm thế nào để có thể phân loại các dự án và hướng đến một mô hình cho phép bạn gia tăng đầu tư và chỉ phân phối những công việc có giá trị cao (chúng tôi sẽ thảo luận về quản lý tài chính trong Chương 12)? Bạn làm thế nào để phối hợp làm việc trong suốt các chuỗi giá trị?

Chương 8Tiếp nhận các biện pháp kỹ thuật tinh gọn

Hãy ngừng phụ thuộc vào các cuộc điều tra hàng loạt để đảm bảo đạt được chất lượng sản phẩm. Hãy cải thiện tiến trình và nâng cao chất lượng sản phẩm ngay từ bước đi đầu tiên.

− W. EDWARDS DEMING

Khả năng cải tiến hiệu quả phụ thuộc vào việc bạn có thể thường xuyên kiểm thử các ý tưởng với những người dùng thực sự hay không. Cần lưu ý, mức độ chúng ta có thể học hỏi, cập nhật sản phẩm hoặc nguyên mẫu dựa trên phản hồi và tái kiểm thử là một lợi thế cạnh tranh mạnh mẽ. Đây là tuyên bố giá trị của các biện pháp kỹ thuật tinh gọn mà chúng tôi mô tả trong chương này. Andy Hertzfeld, một kỹ sư làm việc cho Apple Macintosh khi mới thành lập, nhấn mạnh rằng:

“Thay vì tranh luận về các ý tưởng phần mềm mới, chúng ta thực sự phải kiểm thử chúng bằng cách viết nhanh ra những nguyên mẫu, giữ lại các ý tưởng tốt nhất và loại các ý tưởng khác. Chúng ta phải luôn thực hiện điều gì đó thể hiện tư duy tốt nhất của mình ở một thời điểm nào đó.”

Trong nhiều tổ chức, triển khai phần mềm vào một môi trường kiểu sản xuất tích hợp vẫn là một tiến trình mất đến vài ngày hoặc thậm chí nhiều tuần. Trong khi đó, các tổ chức coi phần mềm là một lợi thế cạnh tranh chứ không phải khoản đầu tư cần thiết nhưng không thú vị gì thì lại thường đầu tư đáng kể vào việc giảm thời lượng sản xuất. Ví dụ minh họa về những gì có thể ở quy mô phù hợp là trong tháng 5 năm 2011, Amazon đã đạt độ dài thời gian từ khi kích hoạt đến khi đưa vào các hệ thống sản xuất là 11,6 giây, tốc độ lên tới 1.079 lần kích hoạt mỗi giờ kết hợp với hàng nghìn dịch vụ, trong đó có nền tảng của Amazon. Có những lần kích hoạt đã tác động đến 10.000 trang chủ. Tất nhiên là Amazon cũng phải chịu sự chế tài của các quy định như là Đạo luật Sarbanes-Oxley¹ và Tiêu chuẩn PCI-DSS². Lý do chính thúc đẩy Amazon đầu tư vào khả năng này là khiến nó cực rẻ và ít rủi ro cho công nhân khi thiết kế và tiến hành các thử nghiệm trực tuyến thất bại-an toàn được mô tả trong Chương 9 để thu thập dữ liệu từ người dùng thực. Trong nhiều trường hợp, tiến hành một cuộc thử nghiệm không buộc phải trải qua một tiến trình yêu cầu thay đổi quan liêu. Điều này cho phép các nhóm phân phối liên chức năng của Amazon có khả năng kiểm thử các ý tưởng độc đáo nhưng vẫn cảm thấy an toàn khi hiểu rằng nếu có gì sai lầm, họ có thể ngừng thử nghiệm mà chỉ tác động đến một lượng nhỏ người dùng trong một khoảng thời gian rất ngắn.

¹ Là một trong những luật căn bản của nghề kế toán, kiểm toán, được ban hành tại Hoa Kỳ năm 2002. Mục tiêu chính nhằm bảo vệ lợi ích của các nhà đầu tư vào các công ty đại chúng bằng cách buộc các công ty này phải cải thiện sự đảm bảo và tin tưởng vào các báo cáo, các thông tin tài chính công khai. (ND)

2 Payment Card Industry Data Security Standard là một tiêu chuẩn an ninh thông tin bắt buộc dành cho các doanh nghiệp lưu trữ, truyền tải và xử lý thẻ thanh toán quản lý bởi năm tổ chức thanh toán quốc tế như Visa, MasterCard, American Express, Discover và JCB. (ND)

Mặc dù tên gọi là như vậy nhưng Phân phối Liên tục không chỉ là việc triển khai sản xuất nhiều lần mỗi ngày. Mục đích của Phân phối Liên tục là làm cho việc triển khai công việc trong các khối nhỏ diễn ra an toàn và kinh tế. Nhờ vậy, thời lượng sản xuất sẽ ngắn hơn, chất lượng cao hơn và chi phí thấp hơn. Vì những lý do đó, nhóm HP FutureSmart đã tái cấu trúc chương trình cơ sở để giảm lộn xộn và giảm thiểu thời lượng từ khi chấp nhận mã đến phần mềm đã được thẩm định và có thể lưu hành. Cuối cùng, Phân phối Liên tục giúp kích hoạt việc triển khai sản xuất an toàn, đều đặn chứ không gây ra thử thách lâu dài và đau đớn buộc bạn phải làm thêm giờ để giải quyết.

Chương này hướng đến những độc giả có mong muốn tìm hiểu về các nguyên tắc và biện pháp Phân phối Liên tục. Đối với những người chỉ cần một bức tranh khái quát, chúng tôi có trình bày một bản tóm tắt chuyên đề về các biện pháp kỹ thuật tinh gọn trong phần sau. Nếu vậy, độc giả có thể bỏ qua phần này để đi đến phần cuối của chương.

NỀN TẢNG CỦA PHÂN PHỐI LIÊN TỤC

Phân phối Liên tục là khả năng đưa những thay đổi – những thử nghiệm, tính năng, sự thay đổi phần cứng, việc sửa lỗi – vào quá trình sản xuất hoặc đến tay một vài người dùng một cách an toàn, nhanh chóng và bền vững. Chúng ta hãy xem xét từng yêu cầu này.

An toàn

Để đảm bảo việc triển khai an toàn, chúng tôi xây dựng một đường ống triển khai (deployment pineline³) để đưa mỗi sự thay đổi được đề xuất vào một bộ gồm vài loại kiểm thử tự động khác nhau, sau đó tiến hành thẩm định thủ công bằng kiểm thử khám phá và kiểm thử tính hữu dụng. Sau đó, chúng ta tiến hành kiểm thử theo chuỗi và kiểm thử lần cuối đối với các kiến trúc đã được thẩm định, cuối cùng đưa các kiến trúc đó vào sản xuất, phân phối hoặc tải lên một kho ứng dụng (phụ thuộc vào loại phần mềm). Một mục đích chính của đường ống triển khai là phát hiện và bác bỏ những thay đổi quá rủi ro, hạn chế suy thoái hoặc đưa chúng ta vượt ra khỏi khuôn khổ hiệu năng được chấp nhận. Một sản phẩm phụ của việc thực hiện đường ống triển khai là chúng ta theo dõi được từng sự thay đổi được đưa ra ở đâu, những kiểm thử nào đã được thực hiện, nó đã trải qua những môi trường nào, ai triển khai... Những thông tin này không có giá trị để làm bằng chứng về sự tuân thủ của nhân viên.

³ Deployment Pipeline chia quy trình chuyển giao phần mềm thành các giai đoạn; mỗi giai đoạn có mục tiêu xác minh chất lượng của các tính năng mới từ một góc độ khác nhau để kiểm định chức năng và tránh lỗi ảnh hưởng đến người dùng. Pipeline sẽ cung cấp phản hồi cho nhóm về việc cung cấp tính năng mới. Ở góc độ trừu tượng hơn, deployment pipeline là quy trình để chuyển phần mềm từ kiểm soát phiên bản đến tay người dùng. Mỗi thay đổi đến phần mềm sẽ đi qua một quy trình phức tạp để được phát hành. (ND)

Một cách nhanh chóng

Chúng ta phải không ngừng giám sát và giảm thời lượng đưa những thay đổi đến tay người dùng. Mary và Tom Poppendieck đặt câu hỏi: “Tổ chức của bạn mất bao lâu để triển khai một sự thay đổi chỉ liên quan đến một dòng mã duy nhất?” Chúng ta giảm thời lượng sản xuất bằng cách đơn giản và tự động hóa tiến trình xây dựng, triển khai, kiểm thử và lưu hành. Chúng ta phải có khả năng điều chỉnh các môi trường kiểm thử theo yêu cầu, triển khai các gói phần mềm trong các môi trường đó và nhanh chóng tiến hành đồng thời một số loại thử nghiệm tự động toàn diện trên hệ thống máy tính. Sử dụng tiến trình này, bạn có thể thêm tự tin rằng phần mềm của chúng ta có thể đưa ra lưu hành. Về cơ bản, những việc này liên quan đến cấu trúc (hoặc tái cấu trúc) sử dụng khả năng kiểm thử và triển khai của bạn. Một tác dụng khác quan trọng của việc này là nhóm sản phẩm có thể nhanh chóng nhận được phản hồi về chất lượng công việc của mình và nhanh chóng phát hiện các vấn đề ngay khi chúng được đưa ra chứ không phải đợi đến giai đoạn tích hợp và kiểm thử sau đó, khi mà bạn chỉ có thể giải quyết chúng với chi phí đắt đỏ hơn nhiều.

Bền vững

Trọng tâm của tất cả những việc này là làm cho Phân phối Liên tục khả thi ở khía cạnh kinh tế khi triển khai theo các nhóm nhỏ. Lý do người ta hiếm khi đưa ra các nhóm làm việc lớn là vì tích hợp các hoạt động phân phối là việc khó khăn và đắt đỏ. Câu thần chú của Phân phối Liên tục chính là: “Nếu nó khó khăn, hãy thực hiện nó thường xuyên hơn và sẵn sàng đối mặt với nó.” Nếu việc tích hợp, kiểm thử và triển khai là việc khó khăn, chúng ta cần thực hiện chúng bất cứ khi nào có ai đó đưa bất kỳ điều gì thành phiên bản kiểm soát. Điều này làm bộc lộ sự lãng phí và thiếu hiệu quả trong tiến trình phân phối của chúng ta, qua đó chúng ta có thể giải quyết những vấn đề đó thông qua cải tiến liên tục. Tuy nhiên, để việc tổ chức công việc theo các nhóm nhỏ có hiệu quả kinh tế, chúng ta cần đầu tư tăng cường kiểm thử và tự động triển khai và tạo dựng một kiến trúc hỗ trợ cho điều đó.

Có hai nguyên tắc vàng về Phân phối Liên tục mà mọi người phải tuân thủ:

1. Nhóm không được phép nói rằng họ đã “hoàn thành” bất kỳ phần công việc nào cho đến khi ai đó tìm thấy mã của họ trên trục quản lý phiên bản (đối với nhiều dịch vụ máy chủ⁴, vị trí của trục này thậm chí còn cao hơn – “hoàn thành” có nghĩa là đã triển khai sản xuất). Trong cuốn Khởi nghiệp tinh gọn, Eric Ries lập luận rằng đối với các tính năng mới mà không phải là những yêu cầu đơn giản của người dùng, nhóm cũng phải tiến hành các thử nghiệm đối với người dùng thực để đánh giá liệu tính năng đó có đem lại kết quả mong muốn không.

⁴ Hosted services là các hệ thống và chức năng IT thuê ngoài. Nhà cung cấp dịch vụ máy chủ sở hữu, giám sát cơ sở hạ tầng, phần mềm và các nhiệm vụ điều hành đồng thời khiến hệ thống sẵn sàng cho các khách hàng, thông thường là qua Internet. (ND)

2. Nhóm phải ưu tiên duy trì hệ thống trong trạng thái sẵn sàng triển khai khi cần thực hiện một công việc mới. Điều này có nghĩa là nếu ở bất kỳ điểm nào mà chúng ta không tự tin là có thể đưa bất kỳ điều gì vào trục quản lý phiên bản và phân phối tới người dùng thông qua một tiến trình tự động và “nhấn nút”, thì chúng ta cần ngừng làm việc và giải quyết vấn đề đó.

Chúng ta cần khẳng định rằng việc kiên định thực hiện các bước này là điều khó khăn và đòi hỏi tính kỷ luật – ngay cả đối với các nhóm nhỏ và nhiều kinh nghiệm.

BÍ QUYẾT

Giúp bạn hiểu rõ hơn về định nghĩa của “Hoàn thành”

Các nhà quản lý HP FutureSmart có một nguyên tắc đơn giản để thúc đẩy thực hiện các nguyên tắc vàng này. Bất cứ khi nào có ai đó muốn chứng minh một tính năng mới (tức là được yêu cầu phải có thể tuyên bố rằng việc đó đã “hoàn thành”), họ sẽ hỏi liệu mã đó đã được tích hợp vào trục chưa, và liệu chức năng mới có được chứng minh trong môi trường tương tự như môi trường sản xuất bằng cách thực hiện các kiểm thử tự động hay không. Người đó chỉ có thể tiếp tục chứng minh tính năng mong muốn nếu câu trả lời cho cả hai câu hỏi trên là “có”.

Trong Chương 6 chúng ta đã bàn về việc nhóm HP FutureSmart đạt được sự gia tăng mạnh mẽ về chất lượng, sản lượng và giảm chi phí. Những cải tiến này có được là nhờ HP FutureSmart đã coi các nguyên tắc Phân phối Liên tục là trọng tâm của hoạt động tái xây dựng của mình. Nhóm loại bỏ các giai đoạn tích hợp và kiểm thử khỏi tiến trình phát triển phần mềm bằng cách đưa việc tích hợp và kiểm thử vào công việc thường nhật của mình. Bạn cũng có thể nhanh chóng chuyển ưu tiên để kịp thời đáp ứng những nhu cầu thay đổi của thị trường sản phẩm và người dùng:

Chúng tôi biết chất lượng của mình trong vòng 24 giờ sau khi thực hiện bất kỳ việc gì trong hệ thống... và chúng tôi có thể kiểm thử rộng rãi ngay cả đối với những thao tác nhỏ vào phút cuối để đảm bảo rằng việc sửa lỗi không gây ra những thất bại không mong muốn. Hoặc chúng tôi có thể đưa ra những tính năng mới ngay sau khi tuyên bố rằng “chức năng hoàn tất” – hoặc trong một số trường hợp đặc biệt, ngay sau khi tuyên bố về một phiên bản dùng thử.

Chúng ta hãy xem xét các cơ cấu kỹ thuật đã giúp cho nhóm HP FutureSmart đạt mức tăng sản lượng gấp tám lần.

TÍCH HỢP LIÊN TỤC VÀ KIỂM THỬ TỰ ĐỘNG

Trong nhiều nhóm phát triển, các nhân viên thường làm việc rất lâu trong nhánh kiểm soát phiên bản. Đối với các nhóm nhỏ làm việc tập trung và có kinh nghiệm, điều này có thể hiệu quả. Tuy nhiên, kết quả tất yếu của việc áp dụng tiến trình này là hiện tượng “địa ngục tích hợp” (integration hell⁵), tức là khi mà các nhóm mất nhiều ngày hoặc nhiều tuần vào việc tích hợp và ổn định các nhánh này để phát hành mã. Giải pháp là tất cả các lập trình viên cần làm việc ngoài trục và tích hợp công việc của họ vào trục ít nhất mỗi ngày một lần. Để làm được như vậy, họ cần học cách chia các phần việc lớn thành các bước tiến nhỏ giúp duy trì khả năng làm việc và phát hành của trục.

⁵ Địa ngục tích hợp nói đến một thời điểm trong sản xuất, khi mà các thành viên trong một nhóm phân phối tích hợp mã cá nhân của họ. Trong môi trường phát triển phần mềm truyền thống, tiến trình tích hợp này hiếm khi êm ả và liền mạch mà thường phải mất nhiều giờ hoặc thậm chí nhiều ngày sửa mã đó để nó có thể tích hợp hoàn toàn. (ND)

Chúng ta thẩm định khả năng làm việc của trục bằng cách thiết kế ứng dụng hoặc dịch vụ mỗi khi có một thay đổi với trục được đưa ra trong quản lý phiên bản. Chúng ta cũng kiểm thử theo đơn vị đối với phiên bản mã mới nhất, và chuyển phản hồi cho nhóm trong một vài phút nếu tiến trình thiết kế hoặc kiểm thử thất bại. Khi đó, nhóm phải giải quyết vấn đề hoặc – nếu vấn đề không thể giải quyết được trong một vài phút – thì phải khôi phục sự thay đổi đó. Như vậy, chúng ta đảm bảo rằng phần mềm của mình luôn trong trạng thái làm việc trong suốt tiến trình phát triển.

Tích hợp liên tục là biện pháp làm việc theo các nhóm nhỏ và dùng kiểm thử tự động để phát hiện và loại bỏ những thay đổi có thể dẫn tới sự thụt lùi. Theo quan điểm của chúng tôi, đây là biện pháp kỹ thuật quan trọng nhất theo tiêu chuẩn linh hoạt, giúp hình thành nền tảng cho phân phối liên tục với yêu cầu là mỗi thay đổi phải đảm bảo khả năng phát hành cho mã trên trục. Tuy nhiên, các nhóm không quen với tích hợp liên tục sẽ thấy khó có thể chấp nhận biện pháp này.

Theo kinh nghiệm của chúng tôi, mọi người có xu hướng chia thành hai trường phái: những người không thể hiểu làm thế nào mà điều đó lại khả thi (đặc biệt là ở quy mô phù hợp) và những người không thể tin rằng người ta lại có cách làm việc nào khác. Chúng tôi đảm bảo với các bạn rằng điều đó là có thể, cả ở quy mô nhỏ và lớn, bất kể lĩnh vực của bạn là gì.

Trước tiên chúng ta hãy giải quyết vấn đề quy mô với hai ví dụ. Thứ nhất, trường hợp nghiên cứu HP FutureSmart chứng minh tính hiệu quả của tích hợp liên tục với một nhóm phân tán gồm 400 người làm việc trong một hệ thống nhúng. Thứ hai, chúng tôi nhận thấy gần như tất cả trong số hơn 10.000 lập trình viên của Google phân tán tại hơn 40 văn phòng khắp thế giới cùng làm việc bên ngoài một cây mã chuẩn. Tất cả những người làm việc bên ngoài cây mã này phát triển và phát hành ngoài trục, và tất cả các kiến trúc đều được tạo ra từ nguồn. Có từ 20 đến 60 sự thay đổi mã được đưa ra mỗi phút, và 50% những thay đổi về mã nền mỗi tháng. Các kỹ sư Google đã xây dựng một hệ thống tích hợp liên tục mạnh mẽ, tại thời điểm năm 2012 đã vận hành hơn 4.000 cấu trúc và 10 triệu bộ kiểm thử (xấp xỉ 60 triệu lần kiểm thử) mỗi ngày.

Tích hợp liên tục không chỉ khả dĩ đối với các nhóm lớn và phân tán – nó còn là tiến trình duy nhất được đánh giá là tăng trưởng hiệu quả mà không phải trải qua các giai đoạn tích hợp, ổn định hoặc “củng cố” đầy tổn thất và khó lường vốn đi kèm với các cách tiếp cận khác, ví dụ như các đường phát hành hoặc các nhánh tính năng. Phân phối Liên tục được thiết kế để loại bỏ những hoạt động này.

NỀN TẢNG CỦA KIỂM THỬ TỰ ĐỘNG

Các trường hợp của Google và HP FutureSmart cho thấy, tiến trình tích hợp liên tục phụ thuộc vào kiểm thử tự động toàn diện. Kiểm thử tự động vẫn còn là vấn đề gây tranh cãi trong một số tổ chức, nhưng bạn không thể đạt được thời lượng sản xuất ngắn và sản phẩm lưu hành chất lượng cao mà không có nó. Kiểm thử tự động là một chủ đề quan trọng và phức tạp mà nhiều cuốn sách hay đã nghiên cứu, nhưng dưới đây là một vài điểm quan trọng nhất:

• Kiểm thử tự động hoàn toàn không phải là việc giảm số lượng nhân viên kiểm thử, mà là sự thay đổi vai trò và kỹ năng cần thiết của các nhân viên kiểm thử. Họ cần tập trung vào kiểm thử khám phá và phối hợp với các lập trình viên để sáng tạo và thiết lập các bộ kiểm thử tự động chứ không phải kiểm thử hồi quy thủ công.

• Không thể xây dựng các bộ kiểm thử tự động chất lượng cao nếu các nhân viên kiểm thử không đích thân phối hợp với các lập trình viên (không cần tính đến nhóm hay các cơ chế báo cáo). Việc xây dựng các hệ thống ổn định để kiểm thử tự động đòi hỏi phải có kiến thức tốt về phát triển phần mềm. Ngay từ đầu, nó cũng đòi hỏi phần mềm phải được thiết kế với chế độ kiểm thử tự động, điều không thể có được nếu các lập trình viên không tham gia kiểm thử.

• Việc duy trì kiểm thử tự động có thể trở thành một cơn ác mộng nếu các bộ kiểm thử tự động không được cấu trúc một cách hiệu quả. Một số lượng nhỏ các cuộc kiểm thử chạy nhanh và đáng tin cậy trong phát hiện lỗi còn tốt hơn là một số lượng lớn các cuộc kiểm thử thường xuyên bị gián đoạn và không nhận được sự quan tâm của các lập trình viên.

• Khi thiết kế kiểm thử tự động, phải suy nghĩ về việc vận hành đồng thời nhiều cuộc kiểm thử khác nhau. Điều này cho phép các lập trình viên nhanh chóng nhận được phản hồi và ngăn chặn những tác động xấu, ví dụ như sự phụ thuộc giữa các cuộc kiểm thử.

Các cuộc kiểm thử tự động hỗ trợ cho các loại kiểm thử khác như kiểm thử khám phá, kiểm thử ứng dụng và kiểm thử an ninh. Ý nghĩa của kiểm thử tự động là thẩm định các tính năng gốc và phát hiện những điểm hạn chế để chúng ta không mất thời gian thực hiện kiểm thử (hoặc triển khai) thủ công các phiên bản phần mềm còn chứa những lỗi nghiêm trọng.

• Các cuộc kiểm thử tự động đáng tin cậy đòi hỏi phải có phương pháp quản lý cấu hình và hạ tầng toàn diện. Nó phải hình thành một môi trường kiểm thử ảo tương tự môi trường sản xuất theo yêu cầu, trong khuôn khổ môi trường tích hợp liên tục hoặc trên máy tính chuyên dụng của lập trình viên.

• Chỉ dành thời gian và nỗ lực để kiểm thử các sản phẩm và tính năng đã được thẩm định. Kiểm thử tự động các thử nghiệm là sự lãng phí.

Các ý kiến phản đối tích hợp liên tục chủ yếu đến từ các lập trình viên và nhà quản lý. Việc phá bỏ từng tính năng mới hoặc tái cấu trúc nỗ lực thành các bước nhỏ là điều còn khó khăn hơn việc hoàn thành nó riêng lẻ trên một nhánh, đồng thời cũng mất nhiều thời gian hơn nếu bạn không quen với nguyên tắc làm việc trong các nhóm nhỏ. Như vậy, ban đầu bạn có thể phải mất nhiều thời gian hơn mới có thể tuyên bố rằng các phần việc đã “kết thúc việc phát triển”. Điều này có thể khiến tốc độ phát triển chậm lại và gây ấn tượng rằng tính hiệu quả của nhóm giảm, khiến cho các nhà quản lý giận dữ.

Tuy nhiên, chúng ta nên tối ưu hóa vì tổng thể thời lượng sản xuất – lượng thời gian sử dụng để đưa được phần mềm có giá trị đến với người dùng. Việc tối ưu hóa vì thời gian “kết thúc việc phát triển” chắc chắn sẽ dẫn đến một “địa ngục tích hợp”. Và khi đó, một “chặng cuối” đầy khó khăn và khó lường của tiến trình tích hợp sẽ làm kéo dài các vòng lưu hành sản phẩm, nguyên nhân chính của tình trạng dự án bị kéo dài, phần mềm chất lượng kém, tổng chi phí cao hơn và người dùng không hài lòng.

CÓ ĐÚNG LÀ BẠN ĐANG THỰC HIỆN TÍCH HỢP LIÊN TỤC?

Tích hợp liên tục (CI) là việc khó, và theo kinh nghiệm của chúng tôi, có nhiều nhóm cho rằng họ đang thực hiện điều đó nhưng thực ra thì không phải. Đạt được CI không đơn giản như việc cài đặt và vận hành một công cụ CI; đó là cả một tư duy. Một trong những tài liệu tâm đắc của chúng tôi về CI bàn về cách thực hiện CI mà không có bất kỳ công cụ CI nào, chỉ sử dụng một máy tính cũ, một chú gà cao su và một chiếc chuông (dĩ nhiên là bạn sẽ cần nhiều hơn thế nếu đang làm việc trong một nhóm phát triển lớn, nhưng các nguyên tắc đều giống nhau ở mọi quy mô.)

Để xem có đúng là bạn đang thực hiện CI không, hãy hỏi nhóm của bạn những câu hỏi sau:

• Có phải tất cả các lập trình viên trong nhóm đều kiểm tra trên trục chính (không chỉ kết hợp trục chính với các nhánh của họ hoặc đơn giản là bắt chước) mỗi ngày ít nhất một lần không? Nói cách khác, họ có đang thực hiện phát triển dựa trên trục chính và làm việc trong các nhóm nhỏ hay không?

• Bất kỳ sự thay đổi nào đối với trục chính có giúp khởi động một tiến trình xây dựng, bao gồm việc vận hành một bộ kiểm thử tự động để phát hiện những điểm hồi quy hay không?

• Khi tiến trình xây dựng và kiểm thử thất bại, nhóm có chữa được lỗi trong vòng vài phút, hoặc bằng cách khắc phục điểm đổ vỡ hoặc bằng cách đảo ngược bước thay đổi đã khiến cho tiến trình thất bại?

Nếu câu trả lời cho bất kỳ câu hỏi nào nói trên là “không” thì bạn đang không thực hành tích hợp liên tục. Đặc biệt, đảo ngược những bước thay đổi tồi là một kỹ thuật được thực hiện một cách không đầy đủ. Ví dụ tại Google, bất kỳ ai cũng được trao quyền đảo ngược một bước thay đổi tồi trong kiểm soát phiên bản, ngay cả khi nếu bước đi đó là do người của nhóm khác thực hiện: Họ ưu tiên duy trì hệ thống hoạt động hơn là thực hiện những việc mới.

Dĩ nhiên nếu bạn đang nghiên cứu một ứng dụng lớn và sử dụng nhiều nhánh, thì không dễ để chuyển sang tích hợp liên tục. Trong tình huống này, nên khuyến khích các nhóm chú ý làm việc theo trục chính, bắt đầu với các nhánh bất ổn nhất. Trong một tổ chức lớn, phải mất hàng năm mới có thể giảm từ 100 nhánh xuống còn khoảng 10-15 nhánh.

ĐƯỜNG ỐNG TRIỂN KHAI⁶

6 Điểm đổ vỡ (Breakage): Tức điểm mà tại đó một người/hệ thống thất bại hoặc mất đi năng lượng.

Xin nhắc lại quy tắc vàng thứ hai của Phân phối Liên tục: Chúng ta phải ưu tiên duy trì hệ thống hoạt động hơn là thực hiện những việc mới. Tích hợp liên tục là một bước quan trọng để hướng đến mục đích này, nhưng về cơ bản, chúng ta sẽ không cảm thấy thoải mái khi đem đến cho người dùng những phần mềm mới chỉ trải qua các cuộc kiểm thử cục bộ.

Nhiệm vụ của đường ống triển khai là đánh giá mọi thay đổi được thực hiện trên hệ thống để phát hiện và bác bỏ những thay đổi có tính rủi ro cao hoặc tác động tiêu cực đến chất lượng, và để cung cấp cho nhóm những phản hồi kịp thời về sự thay đổi của họ để họ có thể giải quyết các vấn đề nhanh chóng và ít tốn kém. Đường ống này đưa tất cả các bước đăng nhập vào kiểm soát phiên bản, tạo ra các gói từ phiên bản đó để có thể triển khai tới bất kỳ môi trường nào, và thực hiện hàng loạt các cuộc kiểm thử đối với phiên bản đó để phát hiện những nhược điểm và thẩm định rằng chức năng quan trọng đó vẫn hoạt động. Nếu gói đó vượt qua được các cuộc kiểm thử này, chúng ta sẽ tự tin triển khai việc xây dựng phần mềm cụ thể đó. Nếu có bất kỳ giai đoạn nào của đường ống triển khai thất bại, thì phiên bản phần mềm đó sẽ không thể tiến xa hơn, và ngay lập tức các kỹ sư phải tập trung tìm ra nguyên nhân của vấn đề và khắc phục nó.

Ngay cả một đường ống triển khai đơn giản nhất, như được thể hiện trong Hình 8-1 (một đường ống triển khai phức tạp hơn được thể hiện trong Hình 8-2), cũng cho phép các thành viên của nhóm thực hiện việc triển khai hoặc kích hoạt các cấu trúc đã trải qua CI trong môi trường kiểm thử khám phá tương tự như môi trường sản xuất hoặc môi trường kiểm thử sự chấp nhận của người dùng. Bạn cần có khả năng cung cấp môi trường kiểm thử và triển khai bất kỳ cấu trúc CI tốt trong các môi trường đó bằng cách sử dụng một tiến trình tự động hoàn toàn. Tiến trình tương tự như vậy cần được áp dụng và triển khai trong quá trình sản xuất.

Đường ống triển khai kết nối tất cả các bước cần thiết để đi từ việc đăng ký đến việc triển khai rồi đến sản xuất (hoặc phân phối tới một kho ứng dụng). Nó cũng kết nối tất cả các bên liên quan vào việc phân phối phần mềm, bao gồm các lập trình viên, nhân viên kiểm thử, kỹ sư phát hành và các chiến dịch – điều giúp nó trở thành một công cụ giao tiếp quan trọng.

Hình 8-1. Những thay đổi diễn ra trên một đường ống triển khai đơn giản

Hình 8-2. Một đường ống triển khai phức tạp hơn

ĐƯỜNG ỐNG TRIỂN KHAI FUTURESMART

Đường ống triển khai của nhóm FutureSmart cho phép một nhóm phân tán gồm 400 người tích hợp 100-150 sự thay đổi – khoảng 75.000-100.000 đường mã – vào trục chính trên mã nền gồm 10 triệu đường của họ mỗi ngày. Mỗi ngày, đường ống triển khai tạo ra 10-14 kết cấu chương trình cơ sở tốt ở Mức 1. Tất cả những thay đổi – bao gồm phát triển tính năng và thay đổi quy mô lớn – đều được thực hiện trên trục chính. Các lập trình viên tham chiếu vào trục vài lần mỗi tuần.

Tất cả những thay đổi đối với bất kỳ hệ thống nào – hay đối với các môi trường mà hệ thống đó hoạt động – cần được thực hiện thông qua việc kiểm soát phiên bản và sau đó thúc đẩy qua đường ống triển khai. Điều đó bao gồm không chỉ mã nguồn và mã kiểm thử mà còn cả việc di chuyển cơ sở dữ liệu và các kịch bản triển khai và dự phòng cũng như là những thay đổi đối với máy chủ, kết nối mạng và các cấu hình hạ tầng.

Vì vậy, đường ống triển khai trở thành biên bản ghi chép lại những hoạt động kiểm thử nào đã được thực hiện trên một kết cấu cụ thể và kết quả là gì, những kết cấu nào đã được triển khai tại môi trường nào và khi nào, ai là người chấp thuận thúc đẩy một kết cấu cụ thể và cấu hình của mọi môi trường chính xác là gì, khi nào – thực sự là toàn bộ vòng đời của những thay đổi về mã và hạ tầng khi chúng đi qua các môi trường khác nhau.

Như vậy, điều này có nghĩa là việc thực hiện đường ống triển khai còn có một vài công dụng quan trọng khác ngoài tác dụng loại bỏ những thay đổi mang tính rủi ro cao hoặc có thể gây rắc rối cho hệ thống:

◆ Bạn có thể thu thập những thông tin quan trọng về tiến trình phân phối, như là những thống kê về vòng đời của những thay đổi (sự cân bằng, sự biến thể tiêu chuẩn) và phát hiện những điểm thắt cổ chai trong tiến trình của mình.

◆ Đường ống triển khai cung cấp vô vàn thông tin về các mục đích kiểm toán và sự phục tùng. Các nhà kiểm toán rất yêu thích phương pháp này vì nó cho phép họ theo dõi chính xác mọi chi tiết những mệnh lệnh nào được vận hành trên các khối nào, kết quả là gì, ai phê chuẩn chúng và khi nào...

◆ Đường ống triển khai có thể tạo nền tảng cho một tiến trình nhỏ nhưng toàn diện để quản lý sự thay đổi. Ví dụ, công ty điện thoại National Broadband Network của Úc, một công ty được kiểm soát rất chặt chẽ, đã sử dụng một đường ống triển khai để tự động đưa ra những thẻ quản lý thay đổi khi các thay đổi được thực hiện đối với hạ tầng sản xuất, và để tự động cập nhật CMDB (Cơ sở dữ liệu quản lý cấu hình – Configuration management database) của họ khi cung cấp các hệ thống mới và tiến hành triển khai.

◆ Đường ống triển khai giúp các thành viên trong nhóm có khả năng thực hiện “bấm nút” để triển khai kết cấu mà họ lựa chọn đến môi trường mà họ lựa chọn. Về cơ bản, các công cụ thực hiện đường ống triển khai về cơ bản cho phép đưa ra những quyết định như vậy dựa trên cơ sở môi trường và thúc đẩy tiến độ củng cố kết cấu.

PHÂN PHỐI LIÊN TỤC VÀ KIỂM SOÁT THAY ĐỔI

Nhiều doanh nghiệp có truyền thống sử dụng các ban cố vấn về thay đổi hoặc các hệ thống kiểm soát thay đổi tương tự để giảm rủi ro của những thay đổi đối với môi trường sản xuất. Tuy nhiên, theo Báo cáo Tình hình Phát triển và Vận hành 2014, sau khi điều tra hơn 9.000 cá nhân ở nhiều ngành công nghiệp, phát hiện ra rằng các tiến trình phê duyệt diễn ra ở ngoài các nhóm phát triển không đem lại nhiều lợi ích trong cải thiện khả năng của các dịch vụ (được tính bằng thời gian khôi phục dịch vụ và tỷ lệ của những thay đổi thất bại), trong khi tiêu tốn rất nhiều các nguồn lực đầu vào (được tính bằng thời lượng tạo ra sự thay đổi và tần suất thay đổi). Nghiên cứu này cũng so sánh các tiến trình phê duyệt thay đổi diễn ra ở ngoài tổ chức với các cơ chế bình duyệt của đồng nghiệp như là lập trình đôi⁶ hoặc sử dụng các yêu cầu kéo⁷. Phân tích các số liệu thống kê cho thấy khi các nhóm kỹ sư quan tâm đến việc khẳng định chất lượng mã thông qua cơ chế bình duyệt của đồng nghiệp, thời lượng sản xuất và tần suất phát hành đã được cải thiện đáng kể mà không tác động nhiều đến sự ổn định của hệ thống. Các thông tin khác trong Báo cáo ủng hộ việc sử dụng các kỹ thuật được thảo luận trong chương này sẽ được trình bày trong Chương 14.

⁶ Pair Programming là kiểu lập trình đòi hỏi hai kỹ sư phần mềm cùng tham gia một nỗ lực lập trình chung trên một máy trạm, nghĩa là chỉ có một màn hình, một bàn phím. Mỗi người thực hiện việc mà người kia hiện không làm. Ví dụ, người này gõ các bộ test đơn vị (unit test), người kia nghĩ về các lớp đầu vào (input) sẽ thỏa mãn bộ test đó; hoặc người này viết mã còn người kia quan sát để hướng dẫn hoặc kiểm lỗi. Người ta khuyên rằng hai người nên luân phiên đổi vai trò, khoảng nửa giờ một lần. (ND)

⁷ Pull request – Một yêu cầu kéo là một phương pháp đệ trình các đóng góp cho một dự án phát triển mở. Điều này thường là cách được ưu tiên đối với việc đệ trình các đóng góp cho một dự án bằng việc sử dụng một hệ thống kiểm soát phiên bản phân tán – DVCS (version control system) như Git. Một yêu cầu kéo xảy ra khi một lập trình viên yêu cầu những thay đổi được đệ trình tới một kho bên ngoài sẽ được xem xét để đưa vào trong một kho chính của dự án. (ND)

Các dữ liệu cho thấy đã đến lúc phải đánh giá lại giá trị mà các tiến trình kiểm soát thay đổi nặng nề đem lại. Cơ chế chuyên gia về thay đổi mã kết hợp với một đường ống triển khai là sự thay thế mạnh mẽ, an toàn, có thể kiểm toán và hiệu quả cao cho cơ chế phê duyệt những thay đổi bên ngoài. Trường hợp nghiên cứu điển hình National Broadband Network (được đề cập ở trên) cho thấy một phương pháp thực thi tiến trình kiểm soát thay đổi nhẹ nhàng phù hợp với những khuôn khổ như là ITIL⁸ trong một môi trường có kiểm soát. Để hiểu thêm về quản lý sự tuân thủ và rủi ro, xem Chương 12.

⁸ Information Technology Infrastructure Library – Thư viện cơ sở hạ tầng IT, là bộ tập hợp các thực hành tốt nhất của Quản lý dịch vụ IT (ISMS) tập trung vào việc sắp xếp các dịch vụ IT sao cho phù hợp với yêu cầu kinh doanh. (ND)

Thực hiện Phân phối Liên tục đòi hỏi phải suy nghĩ thận trọng về kiến trúc và tiến trình của các hệ thống và có kế hoạch trước cho một số hoạt động nhất định. Việc lặp lại bất cứ hoạt động thủ công nào cũng cần được coi là một sự lãng phí tiềm tàng và vì vậy phải được đơn giản và tự động hóa. Việc này bao gồm:

Xây dựng

Bạn cần có khả năng tạo ra các gói từ nguồn, có thể triển khai ở bất kỳ môi trường nào, trong một bước riêng rẽ sử dụng một kịch bản được lưu trữ trong kiểm soát phiên bản và có thể được vận hành bởi bất kỳ lập trình viên nào.

Định hình

Bất kỳ ai cũng nên có khả năng tự phục vụ một môi trường kiểm thử (bao gồm cấu hình mạng, cấu hình máy chủ, bất kỳ phần mềm hay ứng dụng cần thiết nào) một cách tự động hoàn toàn. Tiến trình này cũng cần sử dụng thông tin và kịch bản được lưu trữ trong kiểm soát phiên bản. Những thay đổi đối với cấu hình môi trường luôn cần được thực hiện thông qua kiểm soát phiên bản với chi phí thấp và không gây ra sự cố khi loại bỏ các khối và các lệnh tái định hình từ nguồn.

Triển khai

Bất kỳ ai cũng cần có khả năng triển khai các gói ứng dụng trong bất kỳ môi trường nào mà họ có thể tiếp cận sử dụng một tiến trình tự động hoàn toàn vốn dùng những kịch bản được lưu trữ trong kiểm soát phiên bản.

Kiểm thử

Bất kỳ lập trình viên nào cũng cần có khả năng thực hiện những hoạt động kiểm thử tự động hoàn chỉnh trên máy tính của họ cũng như là bất kỳ bộ kiểm thử chọn lọc nào. Các hoạt động kiểm thử cần toàn diện và nhanh chóng và bao gồm cả các cuộc kiểm thử cấp đơn vị và cấp độ chấp nhận.

Chúng tôi yêu cầu phải có hoạt động quản lý cấu hình xuất sắc để tạo cơ sở cho tự động hóa. Đặc biệt, mọi thứ cần thiết để tái tạo hệ thống sản xuất và để xây dựng, kiểm thử và triển khai các dịch vụ của bạn cần phải nằm trong kiểm soát phiên bản. Những thứ này bao gồm không chỉ mã nguồn mà còn cả các kịch bản xây dựng, kiểm thử và triển khai, cấu hình hạ tầng và môi trường, giản đồ cơ sở dữ liệu và kịch bản di chuyển cũng như các tài liệu.

TÁCH RIÊNG TRIỂN KHAI VÀ PHÁT HÀNH

Nguyên tắc quan trọng nhất cho việc thực hiện những hoạt động phát hành rủi ro thấp là: Hãy tách riêng việc triển khai và phát hành. Để hiểu nguyên tắc này, trước tiên chúng ta phải hiểu định nghĩa của những thuật ngữ này.

Triển khai là việc đưa một phiên bản cụ thể của một bộ phận phần mềm vào một môi trường xác định. Quyết định thực hiện một hoạt động triển khai – bao gồm việc đưa vào vận hành – cần phải là một quyết định kỹ thuật thuần túy. Phát hành là tiến trình đưa một tính năng hoặc một bộ tính năng đến với khách hàng. Phát hành cần phải là một quyết định kinh doanh thuần túy.

Hai thuật ngữ này thường được coi là đồng nghĩa, tức là chúng ta dùng hoạt động triển khai làm cơ chế chính để thực hiện lưu hành. Điều này dẫn đến một hậu quả vô cùng tiêu cực: Nó kết hợp một quyết định triển khai mang tính kỹ thuật với một quyết định phát hành mang tính kinh doanh. Đây là nguyên nhân chính của tình trạng chính trị tổ chức xen vào tiến trình triển khai và gây thiệt hại cho cả tổ chức.

Có một số kỹ thuật triển khai phần mềm tới môi trường sản xuất một cách an toàn mà chưa để người dùng tiếp cận các chức năng của nó, nhờ đó chúng ta có thể xác định rằng hệ thống của chúng ta vận hành đúng hay không. Phương pháp đơn giản nhất – và là một trong những phương pháp mạnh mẽ nhất – là triển khai song song (blue- green deployment, đôi khi được gọi là black-red deployments). Mô hình này cần có hai môi trường vận hành riêng rẽ với mã xanh nước biển và xanh lá cây. Vào bất kỳ thời điểm nào thì cũng chỉ một trong số hai môi trường này ở trong trạng thái hoạt động; trong Hình 8-3, đó là môi trường xanh lá cây.

Hình 8-3. Triển khai song song (được sự đồng ý của Martin Fowler)

Khi muốn phát hành một phiên bản dịch vụ mới, chúng ta triển khai các gói tính năng mới tới môi trường mà hiện không tồn tại (ví dụ trong trường hợp này là xanh nước biển) và kiểm thử nó khi có thời gian. Lúc này tiến trình phát hành chỉ đơn giản là thay đổi bộ định tuyến để chỉ vào môi trường xanh nước biển; để quay lại, chúng ta chỉ bộ định tuyến trở lại môi trường xanh lá cây. Một biến thể phức tạp hơn sẽ dần hình thành đường đến với môi trường xanh nước biển theo thời gian.

Điều quan trọng đối với các công ty có tiến trình triển khai khó khăn và không thể phát hành trong giờ cao điểm là việc triển khai song song cho phép tiến trình triển khai được hoàn thành một cách an toàn vào giờ làm việc bình thường, nhiều ngày trước khi phát hành theo kế hoạch nếu cần thiết. Lúc đó, bạn có thể thực hiện từ xa một tiến trình phát hành đơn giản hơn nhiều (và quay lại nếu cần thiết) trong các giờ thấp điểm với một nhóm nhân viên nhỏ hơn nhiều.

Một số tổ chức sử dụng các trung tâm dữ liệu chính và dữ liệu hỗ trợ cho các môi trường xanh nước biển và xanh lá cây của mình, qua đó chắc chắn rằng họ có thể thực hiện tiến trình khôi phục thảm họa nóng⁹ mỗi khi họ triển khai. Tuy nhiên, môi trường xanh nước biển và môi trường xanh lá cây không phân biệt nhau về cơ học. Chúng có thể là môi trường ảo hoặc môi trường lô-gic vận hành trên cùng một cơ sở hạ tầng vật lý (đặc biệt là vì nhìn chung thì môi trường bất hoạt tiêu thụ rất ít các nguồn lực).

⁹ Hot disaster-recovery: Khi nói đến tốc độ khôi phục dữ liệu, có ba loại khôi phục thảm họa khác nhau: lạnh, ấm và nóng. Khôi phục thảm họa nóng là có một phiên bản hoàn toàn giống trang vận hành của bạn, bao gồm nhân viên, các hệ thống mạng, hệ thống điện và gần như ngay lập tức sao lưu dữ liệu của bạn. Chỉ mất một thời gian rất ngắn để chuyển từ trang chủ đến trang hỗ trợ. (ND)

Triển khai và phát hành cũng có thể được phân biệt theo cấp độ tính năng hoặc thành tố, thay vì cấp độ hệ thống, bằng cách sử dụng một kỹ thuật được gọi là “Ra mắt tối”¹⁰. Khi trao đổi về tiến trình phát hành Facebook, Giám đốc Phát hành Chuck Rossi cho biết, tất cả những tính năng chính dự kiến ra mắt trong 6 tháng tiếp theo đều đã được đưa vào vận hành – chỉ là bạn chưa thể nhìn thấy chúng mà thôi. Các lập trình viên bảo vệ các tính năng mới bằng “các nút tính năng”¹¹ để các nhà điều hành có thể chủ động cho phép một số người dùng cụ thể tiếp cận hệ thống trên cơ sở tính năng. Theo cách này, các tính năng được dành trước tiên cho các nhân viên Facebook, sau đó là một số lượng nhỏ người dùng như là một phần của kiểm thử A/B (xem Chương 9). Sau đó, các tính năng đã thẩm định sẽ dần được đưa đến 100% người dùng và được tắt đi khi lượng tải cao hoặc nếu một nhược điểm bị phát hiện. Các nút tính năng cũng có thể được sử dụng để đưa các bộ tính năng khác nhau đến với các nhóm người dùng khác nhau từ một nền tảng đơn.

10 Dark launching là một tiến trình mà phần mềm được phát hành dần dần và vững chắc tới tay người tiêu dùng để nhận được sự phản hồi của người dùng và kiểm thử hiệu năng. (ND)

¹¹ Feature flags hoặc feature toggles − hệ thống để người dùng có thể bật, tắt các tính năng. (ND)

BÍ QUYẾT

Ra mắt tối (Dark Launching) các ứng dụng di động

Thay vì trực tiếp ra mắt các ứng dụng di động mới tại một kho ứng dụng, hãy xây dựng một thương hiệu riêng để triển khai và thẩm định trước khi ra mắt chúng với thương hiệu chính thức của bạn.

KẾT LUẬN

Phân phối Liên tục là một sự thay thế cho các tiến trình phát triển và phát hành theo nhóm lớn. Nó đã được nhiều tổ chức kỹ thuật lớn hoạt động trên nhiều lĩnh vực khác nhau, bao gồm những ngành công nghiệp có tính kiểm soát cao như các dịch vụ tài chính, chấp thuận. Mặc dù xuất phát từ các dịch vụ mạng, mô hình kỹ thuật này đã được áp dụng thành công vào việc phát triển phần mềm gói, chương trình cơ sở và ứng dụng di động. Nó cho phép các tổ chức phản ứng nhanh chóng với nhu cầu thay đổi của khách hàng và tăng chất lượng phần mềm trong khi giảm rủi ro của việc phát hành, đồng thời giảm chi phí phát triển phần mềm.

Văn hóa cũng đóng vai trò quan trọng trong hỗ trợ Phân phối Liên tục. Một nền văn hóa mà sự tương tác giữa các nhóm phát triển, vận hành và an ninh thông tin thường theo hướng “cùng thắng” thì chắc chắn sẽ đem lại hiệu năng cao, ví dụ như văn hóa “sinh lời” của mô hình Westrum (Chương 1).

Khi các tổ chức làm việc để thực hiện Phân phối Liên tục, họ sẽ phải thay đổi cách tiếp cận kiểm soát phiên bản, phát triển phần mềm, kiến trúc, kiểm thử và quản lý cơ sở hạ tầng và cơ sở dữ liệu. Hình 8-4 được tổng kết từ nghiên cứu của chúng tôi về một số tổ chức khác nhau.

Dĩ nhiên là tất cả phần việc này có quan hệ với nhau. Ví dụ, việc xây dựng một bộ kiểm thử tự động bền vững và toàn diện đòi hỏi phải có một kiến trúc cho phép phần mềm được triển khai tại các máy tính cục bộ của lập trình viên, vì vậy đặt ra yêu cầu phải có khả năng thiết lập những môi trường tương tự như môi trường vận hành bằng các kịch bản kiểm soát phiên bản. Tìm ra những gì cần đạt được trước tiên, trong bối cảnh các hệ thống hiện có, có thể là điều phức tạp. Chúng tôi sẽ thảo luận về thay đổi kiến trúc phát triển trong Chương 10.

Hình 8-4. Triển khai g-forces (được sự đồng ý của Paul Hammant)

Chúng tôi mạnh mẽ khuyến nghị các bạn bắt đầu bằng quản lý cấu hình toàn diện, tích hợp liên tục và phát triển dựa trên trục chính. Một việc cũng rất quan trọng là xây dựng văn hóa kiểm thử tự động cho các lập trình viên, qua đó đòi hỏi phải cung cấp môi trường kiểm thử theo yêu cầu. Theo kinh nghiệm của chúng tôi, các nỗ lực giải quyết khó khăn trong phát hành hay vận hành, được thảo luận trong Chương 14, không thể tạo ra sự cải tiến có ý nghĩa nếu không có tích hợp liên tục, kiểm thử tự động và cung cấp môi trường tự động.

Câu hỏi dành cho độc giả:

◆ Bạn định nghĩa về việc “hoàn thành” một tính năng được chấp thuận là gì? Ít nhất thì tính năng đó phải được tích hợp vào trục chính và được chứng minh trong một môi trường tương tự môi trường vận hành bằng cách thực hiện các cuộc kiểm thử tự động?

◆ Bạn có đang thực hiện tích hợp liên tục như chúng tôi định nghĩa trong cuốn sách này? Bạn sẽ làm thế nào để bắt đầu việc đó?

◆ Mối quan hệ giữa các lập trình viên, các nhân viên kiểm thử và các nhân viên vận hành IT là phối hợp hay mâu thuẫn? Bạn sẽ thực hiện những bước nào để cải thiện điều đó?

◆ Các hoạt động triển khai sản xuất của bạn có phải là những việc khó khăn, “ồn ào” và gây ra sự tức giận khi đã ngoài giờ làm việc? Bạn thay đổi chúng như thế nào để làm được nhiều việc hơn trong giờ làm việc thông thường?

Chương 9Sử dụng cách tiếp cận thử nghiệm để phát triển sản phẩm

Việc khó khăn trong xác định chất lượng là phải chuyển được nhu cầu tương lai của người dùng thành những đặc điểm có thể đo lường, từ đó thiết kế một sản phẩm đem lại sự thỏa mãn tương ứng với mức giá mà người dùng sẽ chi trả.

− WALTER SHEWHART

Cho đến nay, chúng tôi đã dùng toàn bộ Phần III để trình bày cách cải thiện tốc độ đưa giá trị đến với khách hàng. Trong chương này, chúng tôi chuyển trọng tâm vào việc thảo luận sự gắn kết – cách sử dụng khả năng mà chúng ta đã phát triển để đảm bảo chắc chắn rằng chúng ta đang xây dựng sản phẩm đúng cho khách hàng, người dùng và tổ chức của chúng ta.

Trong Chương 7, chúng tôi đã chỉ ra cách sử dụng Chi phí Trì hoãn để sắp xếp thứ tự ưu tiên cho công việc. Trong một tổ chức mà IT thực chất là bộ phận cung cấp dịch vụ thì đây là cách hiệu quả để tránh phải thực hiện những nhiệm vụ giá trị thấp và tiêu tốn những khoảng thời gian và nguồn lực quý báu. Tuy nhiên, trong các tổ chức hiệu năng cao, người ta không giao phó toàn bộ các dự án và các yêu cầu cho bộ phận IT. Thay vào đó, các kỹ sư, nhà thiết kế, nhân viên kiểm thử, nhân viên vận hành và nhà quản lý sản phẩm phối hợp làm việc để đem lại kết quả giá trị cao cho khách hàng, người dùng và toàn bộ tổ chức. Hơn nữa, những quyết định này, mang tính cục bộ trong các nhóm, đều dựa trên các mục đích chiến lược rộng hơn của tổ chức.

Trong Chương 6, chúng tôi mô tả phương pháp Kata Cải tiến – cách tiếp cận tái lặp nhằm cải thiện tiến trình, theo đó chúng ta đặt điều kiện mục tiêu cho vòng lặp tiếp theo và cho các nhóm quyền quyết định phải làm gì để đạt được những điều kiện mục tiêu đó. Sự cải tiến chính mà chúng tôi trình bày trong chương này là sử dụng một tiến trình tương tự để quản lý phát triển sản phẩm. Thay vì đặt ra các yêu cầu hay các trường hợp sử dụng (use case¹) và đưa chúng vào khối công việc còn tồn đọng để các nhóm thực hiện theo thứ tự ưu tiên, chúng ta mô tả, bằng những chỉ số có thể đo lường, những kết quả kinh doanh mà chúng ta muốn đạt được trong vòng lặp tiếp theo. Sau đó sẽ tùy thuộc vào các nhóm để khám phá những ý tưởng về các tính năng có thể giúp đạt được kết quả này, kiểm thử chúng và xây dựng những tính năng có thể giúp đạt được kết quả mong muốn. Bằng cách này, chúng ta khai thác được kỹ năng và sự khéo léo của toàn bộ tổ chức để đi đến những ý tưởng giúp đạt được mục đích kinh doanh với mức lãng phí nhỏ nhất và với tốc độ nhanh nhất.

¹ Use case là một kỹ thuật được dùng trong kỹ thuật phần mềm và hệ thống để nắm bắt yêu cầu chức năng của hệ thống. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (actor) và hệ thống. Nó thể hiện ứng xử của hệ thống đối với bên ngoài, trong một hoàn cảnh nhất định, xét từ quan điểm của người sử dụng. Nó mô tả các yêu cầu đối với hệ thống, có nghĩa là những gì hệ thống phải làm chứ không phải mô tả hệ thống làm như thế nào. Tập hợp tất cả Use case của hệ thống sẽ mô tả tất cả các trường hợp mà hệ thống có thể được sử dụng. (ND)

Là một cách tiếp cận trong thực hiện phát triển phần mềm linh hoạt ở quy mô phù hợp, quy trình này khác với nhiều khuôn khổ khác. Không có khối lượng công việc tồn đọng ở cấp độ tổng quan; thay vào đó, các nhóm xác định và quản lý công việc tồn đọng của chính họ và có trách nhiệm phối hợp để đạt được mục đích kinh doanh. Những mục đích này được chuyển thành điều kiện mục tiêu ở cấp độ tổng quan và thường xuyên được cập nhật như là một phần của tiến trình Kata Cải tiến (xem Chương 6). Như vậy, trách nhiệm đạt mục tiêu kinh doanh được chuyển cho các nhóm, và các nhóm sẽ tập trung cho kết quả kinh doanh chứ không phải các chỉ số như lượng công việc hoàn thành (tốc độ nhóm), số dòng mã được viết ra hay số lượng giờ làm việc. Mục đích thực sự là giảm thiểu sản lượng trong khi tăng tối đa kết quả; chúng ta viết càng ít dòng mã và càng làm việc ít giờ mà vẫn đạt được mục đích kinh doanh mong muốn thì càng tốt. Các hệ thống cồng kềnh, phức tạp và đội ngũ nhân viên kiệt sức là những dấu hiệu cho thấy tình trạng tập trung vào sản lượng chứ không phải kết quả.

Một việc mà chúng tôi không làm trong chương này (hoặc đúng ra trong cuốn sách này) là mô tả những tiến trình mà các nhóm cần sử dụng để quản lý công việc. Các nhóm có thể – và nên – được tự do lựa chọn bất kỳ phương pháp và tiến trình nào tốt nhất cho họ. Thực tế là trong chương trình HP FutureSmart, các nhóm khác nhau đã sử dụng thành công các phương pháp khác nhau và không có nỗ lực nào nhằm áp đặt một tiến trình hay phương pháp “tiêu chuẩn” cho tất cả các nhóm. Điều quan trọng là các nhóm có thể phối hợp làm việc hiệu quả để đạt được các điều kiện mục tiêu.

Vì vậy, chúng tôi không trình bày các phương pháp linh hoạt tiêu chuẩn như là XP, Scrum hay những phương pháp thay thế như Kanban. Có một số cuốn sách tuyệt vời đã viết vô cùng chi tiết về các phương pháp này, ví dụ như cuốn của David Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (tạm dịch: Kanban: Sự thay đổi phát triển thành công cho doanh nghiệp công nghệ của bạn), cuốn sách của Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process (tạm dịch: Scrum Quan trọng: Hướng dẫn thực tế cho nhiều tiến trình linh hoạt phổ biến nhất) và cuốn của Mitch Lacey, The Scrum Field Guide: Practical Advice for Your First Year (tạm dịch: Hướng dẫn về lĩnh vực Scrum: Lời khuyên thực tế cho năm đầu tiên của bạn). Thay vào đó, chúng tôi thảo luận cách phối hợp giữa các nhóm nhằm xác định các cách tiếp cận để đạt được điều kiện mục tiêu, sau đó thiết kế các thử nghiệm để kiểm thử những giả định mà họ đưa ra.

Các kỹ thuật được mô tả trong chương này đòi hỏi sự tin cậy cao độ giữa các bộ phận khác nhau của tổ chức có liên quan đến chuỗi giá trị phát triển sản phẩm cũng như giữa các lãnh đạo, các nhà quản lý và cấp dưới. Chúng cũng đòi hỏi phải có các nhóm hiệu năng cao và thời lượng sản xuất ngắn. Như vậy, nếu những nền tảng này (được mô tả trong các chương trước thuộc phần này) không sẵn sàng, thì việc thực hiện những kỹ thuật này sẽ không đem lại giá trị mà chúng có khả năng tạo ra.

SỬ DỤNG SƠ ĐỒ TÁC ĐỘNG (IMPACT MAPPING) ĐỂ XÂY DỰNG GIẢ THIẾT CHO VÒNG LẶP TIẾP THEO

Kết quả của tiến trình lập kế hoạch vòng lặp Kata Cải tiến (được mô tả trong Chương 6) là một danh sách các điều kiện mục tiêu có thể đo lường mà chúng ta mong muốn đạt được trong vòng lặp tiếp theo, trong đó mô tả ý định về những gì chúng ta đang cố gắng đạt được và tuân thủ Yêu cầu Nhiệm vụ (xem Chương 1). Trong chương này, chúng tôi mô tả cách sử dụng một tiến trình tương tự để thúc đẩy phát triển sản phẩm. Chúng ta đạt được điều này bằng cách thiết lập các điều kiện mục tiêu dựa trên khách hàng và các kết quả của tổ chức, coi đó là một phần của tiến trình lập kế hoạch tái lặp bên cạnh các điều kiện mục tiêu cải thiện tiến trình. Điều này cho phép chúng ta vận dụng cải tiến không ngừng ở cấp độ tổng quan vào việc phát triển sản phẩm bằng cách tiếp cận định hướng mục đích cho quy trình công nghệ yêu cầu (requirements engineering²).

² Requirements engineering, còn gọi là phân tích yêu cầu – là công việc bao gồm các nhiệm vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người dùng, đưa ra. (ND)

Các điều kiện mục tiêu phát triển sản phẩm mô tả các mục tiêu khách hàng hoặc mục tiêu kinh doanh mà chúng ta mong muốn đạt được. Các điều kiện này được thúc đẩy bởi chiến lược sản phẩm của chúng ta. Ví dụ như tăng doanh thu trên mỗi người dùng, nhằm vào một thị phần mới, giải quyết một vấn đề mà một người cụ thể trải nghiệm, tăng hiệu năng của hệ thống hoặc giảm chi phí giao dịch. Tuy nhiên, chúng tôi không đề xuất các giải pháp để giành lấy những mục tiêu này hay nêu ra các công việc hoặc tính năng ở cấp độ tổng quan.

Thay vào đó, tùy thuộc vào các nhóm trong chương trình, chúng ta có thể đưa ra quyết định về cách mà họ sẽ sử dụng để đạt được những mục tiêu này. Điều này rất quan trọng để có thể đạt hiệu năng cao ở quy mô phù hợp vì hai lý do:

(1) Những giải pháp ban đầu mà chúng ta đưa ra không chắc đã là tốt nhất. Những giải pháp tốt hơn được phát hiện bằng cách sáng tạo, kiểm thử và chọn lọc trong nhiều lựa chọn để biết được điều gì sẽ giúp giải quyết vấn đề một cách tốt nhất lúc này.

(2) Các tổ chức chỉ có thể hoạt động nhanh ở quy mô phù hợp khi những người xây dựng giải pháp có hiểu biết sâu sắc về cả nhu cầu của người dùng và chiến lược kinh doanh để xây dựng ý tưởng riêng cho mình.

Một khối lượng công việc tồn đọng ở cấp độ tổng quan không phải là cách hiệu quả để thúc đẩy những xu hướng này – nó chỉ phản ánh xu hướng mà con người hầu như không thể cưỡng lại được, đó là cụ thể hóa “các phương tiện để làm điều gì đó chứ không phải là kết quả mà chúng ta mong muốn”.

BÍ QUYẾT ĐẠT ĐẾN CÁC ĐIỀU KIỆN MỤC TIÊU

Quy trình công nghệ yêu cầu mang định hướng mục đích đã được sử dụng trong nhiều thập kỷ, nhưng nhiều người vẫn quen xác định công việc theo tính năng và lợi ích chứ không phải là kết quả kinh doanh và kết quả khách hàng cụ thể. Thay vào đó, rất tự nhiên là cách tiếp cận tính năng-và-lợi nhuận khiến chúng ta thiên vị cho việc tìm kiếm các giải pháp và chúng ta phải suy nghĩ vất vả hơn để chỉ rõ những thuộc tính sẽ có ở một giải pháp có thể chấp nhận được.

Nếu bạn có các tính năng, lợi nhuận và bạn muốn xác định các điều kiện mục tiêu, một cách tiếp cận đơn giản là đặt câu hỏi tại sao khách hàng của chúng ta quan tâm đến một lợi ích cụ thể. Bạn có thể cần phải hỏi “tại sao” một vài lần thì mới đạt được điều gì đó giống với một điều kiện mục tiêu thực sự. Một điều quan trọng khác là phải đảm bảo rằng các điều kiện mục tiêu có những tiêu chí chấp nhận có thể đo lường, như được thể hiện trong Hình 9-1.

Gojko Adzic trình bày một kỹ thuật được gọi là sơ đồ tác động³ để chia nhỏ các mục đích kinh doanh cấp cao ở cấp độ tổng quan thành “một hình dung về phạm vi và các giả định ngầm hiểu chung, được phối hợp tạo ra bởi một nhóm liên chức năng gồm các bên liên quan. Đó là một sơ đồ tư duy được phát triển trong một cuộc thảo luận được thúc đẩy với việc trả lời các câu hỏi sau: 1. Tại sao? 2. Ai? 3. Làm thế nào? 4. Cái gì. Một ví dụ về sơ đồ tác động được thể hiện trong Hình 9-1.

³ Impact mapping là kỹ thuật xây dựng sự hiểu biết chung giữa lãnh đạo và nhân viên, được tổ chức theo hình thức các cuộc hội thảo khuyến khích đổi mới sáng tạo. (BTV)

Hình 9-1. Một ví dụ về đồ họa tác động, được sự cho phép của Gojko Adzic

Chúng ta bắt đầu hình thành một sơ đồ tác động bằng một điều kiện mục tiêu cấp độ tổng quan. Theo Yêu cầu Nhiệm vụ, khi làm rõ một điều kiện mục tiêu, bao gồm mục đích của điều kiện đó (tức là tại sao chúng ta quan tâm tới điều kiện đó xét từ tầm nhìn kinh doanh), chúng ta có thể chắc chắn rằng mọi người hiểu mục đích của những gì họ đang làm. Chúng ta cũng đưa ra những tiêu chí chấp nhận rõ ràng để có thể quyết định khi nào thì ta đã đạt được điều kiện mục tiêu.

Cấp độ đầu tiên của một sơ đồ tác động liệt kê tất cả các bên liên quan có quan tâm đến điều kiện mục tiêu đó. Họ bao gồm không chỉ những người dùng cuối, những người sẽ chịu tác động của công việc, mà còn người trong tổ chức, những người sẽ liên quan hoặc bị tác động, hay có thể ảnh hưởng đến tiến triển công việc, theo hướng cả tích cực và tiêu cực.

Cấp độ thứ hai của một sơ đồ tác động mô tả những phương cách khả dĩ mà các bên liên quan có thể sử dụng để hỗ trợ – hoặc cản trở – việc đạt được điều kiện mục tiêu. Những thay đổi thái độ như thế này là những tác động mà chúng ta dự định tạo ra.

Cho đến lúc này, chúng ta chưa nên nói gì về những giải pháp khả dĩ để tiến đến điều kiện mục tiêu. Chỉ khi đến cấp độ thứ ba của sơ đồ tác động, chúng ta mới đề xuất những phương án nhằm giành được điều kiện mục tiêu đó. Đầu tiên, chúng ta nên đề xuất những giải pháp không liên quan đến viết mã – như là các hoạt động tiếp thị hay đơn giản hóa các tiến trình kinh doanh. Phát triển phần mềm luôn nên là phương cách cuối cùng do chi phí và tính phức tạp của việc xây dựng và duy trì phần mềm.

Những giải pháp khả dĩ được đề xuất trong sơ đồ tác động không phải là chìa khóa để phân phát cho mọi người. Việc xác định những giải pháp khả dĩ chỉ đơn giản là giúp chúng ta hiểu rõ về mục đích và các bên liên quan. Các giải pháp mà chúng ta xác định ở giai đoạn này không chắc đã phải là tốt nhất – thay vào đó, chúng ta hy vọng rằng các nhân viên tham gia vào quá trình làm việc để đem lại kết quả sẽ tìm được những lựa chọn tốt hơn và đánh giá chúng, qua đó xác định những phương án nào sẽ giúp chúng ta đạt được điều kiện mục tiêu một cách tốt nhất. Sơ đồ tác động có thể được coi là một tập hợp những giả định – ví dụ, trong Hình 9-1, chúng tôi giả định rằng việc tiêu chuẩn hóa các mã ngoại lệ⁴ sẽ giảm các mệnh lệnh phi tiêu chuẩn, giúp giảm chi phí xử lý các giao dịch phi chuẩn.

⁴ Mã ngoại lệ hay mã lỗi (exeption code): Là loại mã dùng để phân loại lỗi. (BTV)

Để công cụ này làm việc hiệu quả, điều quan trọng là phải tìm được đúng người để tham gia thực hiện sơ đồ tác động. Đó có thể là một nhóm nhỏ liên chức năng bao gồm các bên liên quan đến doanh nghiệp, đội ngũ kỹ thuật, các nhà thiết kế, bảo vệ sản phẩm (khi phù hợp), các hoạt động IT và bộ phận hậu cần. Nếu chỉ có các bộ phận kinh doanh thực hiện việc này, thì họ sẽ mất cơ hội kiểm tra những giả định đằng sau các điều kiện mục tiêu và nhận ý kiến từ các nhà thiết kế và các kỹ sư, những người bám vấn đề sát nhất. Một trong những mục đích quan trọng nhất của sơ đồ tác động là tạo hiểu biết chung giữa các bên liên quan, vì thế việc không kéo họ cùng tham gia thực hiện sẽ khiến việc này trở nên không thích hợp.

Sau khi đã có danh sách các điều kiện mục tiêu ưu tiên và các sơ đồ tác động được tạo ra bởi các kỹ sư và nhân viên kinh doanh, các nhóm có quyền quyết định con đường khả dĩ và ngắn nhất để đạt đến điều kiện mục tiêu.

Công cụ này rất khác với nhiều các tiếp cận tiêu chuẩn trong suy nghĩ về những yêu cầu. Dưới đây là một vài khác biệt quan trọng:

Không có danh sách tính năng ở cấp độ tổng quan

Các tính năng đơn giản chỉ là một cơ chế để đạt mục đích. Chúng ta có thể hiểu Adzic như thế này, nếu việc đạt được điều kiện mục tiêu bằng một bộ tính năng hoàn toàn khác những gì mà chúng ta dự tính không được coi là thành công, thì chúng ta đã chọn điều kiện mục tiêu sai. Làm rõ các điều kiện mục tiêu chứ không phải các tính năng cho phép chúng ta có khả năng phản ứng nhanh trước những thay đổi của môi trường và trước những thông tin thu thập từ các bên liên quan khi chúng ta làm việc để đạt đến điều kiện mục tiêu. Việc này ngăn chặn “tỷ lệ ngưng sử dụng tính năng” trong vòng lặp đó. Điều quan trọng nhất, đây là cách hiệu quả nhất giúp tận dụng tài năng của những người làm việc cho chúng ta; khuyến khích họ bằng cách trao cho họ cơ hội theo đuổi sự tinh thông, tự chủ và mục đích của mình.

Không có đánh giá chi tiết

Chúng ta hướng đến một danh sách các điều kiện mục tiêu để đạt đến mục đích – nói cách khác, nếu tất cả các giả định của chúng ta đều tốt và tất cả những dự đoán của chúng ta thành hiện thực, chúng ta cho rằng có thể đạt được chúng. Tuy nhiên, điều này hiếm khi xảy ra, có nghĩa là chúng ta không thể đạt được một vài trong số các điều kiện mục tiêu có độ ưu tiên thấp. Nếu thường xuyên đạt được rất ít các điều kiện mục tiêu, chúng ta cần tái cân bằng chúng theo hướng phục vụ mục đích cải thiện tiến trình. Duy trì các vòng lặp ngắn – ban đầu từ 2-4 tuần – cho phép chúng ta điều chỉnh các điều kiện mục tiêu để đáp ứng những gì mà chúng ta khám phá trong vòng lặp đó. Điều này cho phép chúng ta nhanh chóng phát hiện mình có đang đi sai đường hay không và kiểm thử một cách tiếp cận khác trước khi đầu tư quá mức vào những việc sai lầm.

Không có cái gọi là “những trường ca kiến trúc⁵”. Những người đang làm việc cần có tự do hoàn toàn để thực hiện bất kỳ hoạt động cải tiến nào mà họ muốn (bao gồm thay đổi kiến trúc, tự động hóa và tái cấu trúc) để đạt được điều kiện mục tiêu một cách tốt nhất. Nếu muốn thúc đẩy các mục đích cụ thể, một công việc liên quan đến cấu trúc như việc tuân thủ hoặc cải tiến hiệu năng, chúng ta phải làm rõ những điều này trong các điều kiện mục tiêu của mình.

⁵ Architecture Epic là những sáng kiến công nghệ lớn cần thiết để thúc đẩy các giải pháp đầu tư hỗ trợ các nhu cầu kinh doanh hiện tại và trong tương lai. Architecture Epic được phân tích trong Hệ thống Kanban Architecture Epics. (ND)

THỰC HIỆN NGHIÊN CỨU NGƯỜI DÙNG

Sơ đồ tác động cung cấp cho chúng ta một số giải pháp khả dĩ và một bộ những giả định cho mỗi giải pháp tiềm tàng. Nhiệm vụ của chúng ta là tìm ra con đường ngắn nhất để đạt tới điều kiện mục tiêu. Chúng ta lựa chọn những con đường có vẻ ngắn nhất và xác định giải pháp – cùng với những giả định mà nó đưa ra – để xem liệu giải pháp đó thực sự có khả năng đem lại giá trị mong muốn hay không (như chúng ta thấy, các tính năng thường không đem lại giá trị mong muốn). Có nhiều cách để đánh giá các giả định của chúng ta.

Trước tiên, chúng ta hình thành một giả thiết dựa trên giả định của mình. Trong Lean UX, Josh Seiden và Jeff Gothelf gợi ý sử dụng mô hình như trong Hình 9-2 làm điểm khởi đầu của việc hình thành các giả thiết.

Hình 9-2. Mô hình phát triển theo định hướng giả thiết của Jeff Gothelf

Theo mô hình này, chúng ta mô tả các thông số của thử nghiệm mà chúng ta sẽ tiến hành để kiểm thử giá trị của tính năng được đề xuất. Kết quả của nó mô tả điều kiện mục tiêu mà chúng ta muốn đạt được.

Cũng như mô hình phần việc linh hoạt, chúng ta tóm lược công việc (ví dụ, tính năng mà chúng ta muốn tạo dựng hoặc sự thay đổi tiến trình kinh doanh mà chúng ta muốn thực hiện) chỉ trong một vài từ để dễ dàng nhớ lại nội dung trao đổi trong nhóm về công việc đó. Chúng ta cũng chỉ rõ chân dung khách hàng vì khi thực hiện thử nghiệm, chúng ta sẽ xem xét thái độ của họ. Cuối cùng, chúng ta làm rõ dấu hiệu cần quan tâm đánh giá trong thử nghiệm. Trong các thử nghiệm kiểm soát trực tuyến, được thảo luận trong phần tiếp theo, đây được coi là tiêu chí đánh giá chung.

Hình 9-3. Các loại nghiên cứu người dùng khác nhau, được sự cho phép của Janice Fraser

Khi đã có một giả thiết, chúng ta có thể bắt đầu thiết kế một thử nghiệm. Đây là một hoạt động liên chức năng đòi hỏi phải có sự phối hợp giữa các chuyên gia thiết kế, phát triển, kiểm thử, vận hành công nghệ và phân tích, với sự hỗ trợ của các chuyên gia khi cần. Mục đích là giảm thiểu số lượng công việc phải thực hiện để thu thập đủ lượng dữ liệu nhằm thẩm định hoặc bác bỏ những giả định trong giả thiết của chúng ta. Có nhiều loại nghiên cứu người dùng mà chúng ta có thể thực hiện để kiểm thử giả thiết của mình, như được thể hiện trong Hình 9-3. Để tìm hiểu thêm về các loại nghiên cứu người dùng khác nhau, hãy đọc cuốn UX for Lean Startups (tạm dịch: Trải nghiệm người dùng cho doanh nghiệp khởi nghiệp tinh gọn) của Laura Klein.

Điểm then chốt của cách tiếp cận thử nghiệm trong phát triển sản phẩm là chúng ta sẽ không thực hiện các công việc phát triển mới mà trước đó không xây dựng một giả thiết để có thể khẳng định liệu công việc của mình có đem lại giá trị mong muốn hay không.

CÁC THỬ NGHIỆM KIỂM SOÁT TRỰC TUYẾN

Trong trường hợp một dịch vụ dựa trên Internet, chúng ta có thể sử dụng một phương pháp hiệu quả được gọi là thử nghiệm kiểm soát trực tuyến, hoặc là kiểm thử A/B, để kiểm thử một giả thiết. Một cuộc kiểm thử A/B là một thử nghiệm ngẫu nhiên nhưng có kiểm soát để phát hiện phiên bản nào trong số hai phiên bản khả dĩ của một trang web tạo ra kết quả tốt hơn. Khi thực hiện kiểm thử A/B, chúng ta chuẩn bị hai phiên bản của một trang: một trang kiểm soát (thường là phiên bản hiện tại của trang này) và một giải pháp mới mà chúng ta muốn kiểm thử. Khi một người dùng lần đầu tiên truy cập trang web của chúng ta, hệ thống sẽ quyết định người dùng đó là chủ thể của thử nghiệm nào, và đối với mỗi thử nghiệm lại chọn ngẫu nhiên xem liệu họ sẽ quan tâm đến kiểm soát (A) hay giải pháp (B). Chúng ta kết hợp càng nhiều càng tốt sự tương tác của người dùng với hệ thống để phát hiện bất kỳ sự khác biệt nào trong thái độ giữa kiểm soát và giải pháp.

NHIỀU Ý TƯỞNG HAY THỰC RA KHÔNG ĐEM LẠI KẾT QUẢ, THẬM CHÍ CÒN TẠO RA CÁC GIÁ TRỊ TIÊU CỰC

Có lẽ kết quả rõ nhất của kiểm thử A/B là nó cho thấy làm thế nào mà nhiều ý tưởng rõ ràng là rất hay nhưng lại không giúp cải thiện giá trị. Như thảo luận trong Chương 2, dữ liệu thu thập được từ các cuộc kiểm thử A/B của Ronny Kohavi, người lãnh đạo nhóm Khai thác Dữ liệu và Cá nhân hóa của Amazon trước khi gia nhập Microsoft làm Tổng Quản lý của bộ phận Nền tảng Thử nghiệm (Experimentation Platform), cho thấy có từ 60-90% các ý tưởng không giúp cải thiện được thông số mà họ định cải tiến.

Vì vậy, nếu chúng ta đang không tiến hành thử nghiệm để kiểm thử giá trị của các ý tưởng mới trước khi hoàn tất việc phát triển chúng, thì khả năng là có đến khoảng 2/3 công việc chúng ta đang làm hoặc là không đem lại giá trị hoặc chỉ đem lại giá trị tiêu cực cho khách hàng mà thôi – và chắc chắn là sẽ đem lại giá trị tiêu cực cho tổ chức bởi vì chúng ta phải chi trả cho việc này theo nhiều cách khác nhau. Cùng với chi phí cho phát triển các tính năng, chúng ta còn mất chi phí cơ hội khi mà lẽ ra chúng ta đã có thể thực hiện nhiều việc có giá trị hơn, đồng thời cả chi phí xuất phát từ việc các tính năng đó làm gia tăng tính phức tạp cho hệ thống (bao gồm chi phí duy trì mã, giảm mức độ phát triển chức năng mới, và thông thường là giảm tính ổn định cũng như hiệu năng trong quá trình vận hành).

Mặc dù có những hệ quả nặng nề như thế nhưng nhiều tổ chức vẫn thấy khó có thể tiến hành thử nghiệm để đánh giá giá trị của các tính năng hay sản phẩm mới. Một số nhà thiết kế và hiệu chỉnh cảm thấy điều đó thách thức chuyên môn của họ. Các nhà điều hành thì lo rằng việc đó sẽ đe dọa công việc của họ với tư cách là người ra quyết định và họ có thể mất khả năng kiểm soát các quyết định.

Kohavi, người đưa ra thuật ngữ HiPPO, mô tả rằng công việc của ông là “nói với các khách hàng rằng em bé mới sinh của họ thật xấu xí” và kéo vòng quanh những con hà mã đồ chơi bằng cao su⁶ để cải thiện tâm trạng của họ và nhắc nhở họ rằng nhiều ý tưởng “hay” thực ra lại không hay, và không thể nói chắc điều gì khi không đủ thông tin để biết những gì sẽ là vô dụng.

⁶ Ở đây, tác giả chơi chữ vì “HiPPO” viết thường có nghĩa là “Con hà mã”. (ND)

Bằng cách thực hiện thử nghiệm với một số lượng đủ lớn người dùng, chúng ta thu thập đủ thông tin để chứng minh sự khác biệt quan trọng về thống kê giữa A và B đối với thông số kinh doanh mà chúng ta quan tâm, được gọi là chỉ tiêu đánh giá chung, hoặc OEC (so sách với Thông số Chính trong Chương 4). Kohavi đề xuất đánh giá và tối ưu hóa giá trị vòng đời khách hàng chứ không phải doanh thu trong ngắn hạn. Đối với một trang mạng như Bing, ông đề xuất sử dụng một tổng trọng số gồm các yếu tố như thời gian truy cập mỗi tháng và tần suất truy cập của mỗi người dùng với mục đích cải tiến trải nghiệm khách hàng nói chung và thu hút họ quay trở lại.

Không chỉ giúp phát hiện những mối quan hệ như tiến trình khai thác dữ liệu (data mining⁷), kiểm thử A/B có khả năng chỉ ra mối quan hệ nhân quả giữa một sự thay đổi trên trang mạng và sự thay đổi tương ứng của thông số mà chúng ta quan tâm. Các công ty như Amazon và Microsoft cũng thường xuyên tiến hành hàng trăm các thử nghiệm tại mọi thời điểm trong quá trình sản xuất và kiểm thử mọi tính năng mới bằng phương pháp này trước khi cho lưu hành. Mỗi khách hàng truy cập Bing, dịch vụ tìm kiếm trên mạng của Microsoft, sẽ tham gia khoảng 15 thử nghiệm một lúc.

⁷ Data Mining là quá trình tìm kiếm các mẫu từ tập dữ liệu lớn (Data Set) và phân tích dữ liệu từ những quan điểm khác nhau, cho phép người dùng trong doanh nghiệp dùng để phân tích dữ liệu từ nhiều góc độ khác nhau và tóm tắt các mối quan hệ xác định. (ND)

SỬ DỤNG KIỂM THỬ A/B ĐỂ TÍNH CHI PHÌ TRÌ HOÃN TRONG CẢI TIẾN HIỆU NĂNG

Tại Microsoft, nhóm của Ronny Kohavi muốn tính toán tác động của việc cải tiến hiệu năng của các lệnh tìm kiếm Bing. Giải pháp của họ là tiến hành một cuộc kiểm thử A/B, trong đó họ đưa ra một sự trì hoãn giả trên máy chủ cho người dùng, những người thấy phiên bản “B”. Họ tính được số tiền có được từ tác động của cải tiến hiệu năng đối với doanh thu và khám phá ra rằng “một kỹ sư cải tiến hiệu năng máy chủ được 10/1000 giây sẽ trả đủ cho toàn bộ các chi phí hàng năm của anh ta”. Phép tính này có thể được dùng để đánh giá chi phí trì hoãn của việc cải tiến hiệu năng.

Khi thiết kế một thử nghiệm như là một phần của kiểm thử A/B, mục đích của chúng ta là tìm ra cách làm ít việc hơn nhiều mức thông thường mà vẫn thực thi đầy đủ tính năng đang cân nhắc. Chúng ta có thể tính toán lượng tối đa công việc cần làm trong một thử nghiệm bằng cách xác định giá trị mong đợi của thông tin mà chúng ta sẽ nhận được từ việc thực hiện thử nghiệm đó (xem Chương 3), mặc dù về cơ bản chúng ta sẽ làm ít hơn mức này rất nhiều.

Đối với một trang mạng, có một vài cách để giảm chi phí thực hiện thử nghiệm:

Sử dụng nguyên tắc 80/20 và đừng lo các trường hợp đặc biệt

Xây dựng 20% khả năng hoạt động để đem lại 80% lợi nhuận mong muốn.

Đừng xây dựng với quy mô lớn

Các thử nghiệm trên một trang mạng bận rộn thường chỉ được một số lượng phần trăm rất nhỏ người dùng quan tâm.

Đừng băn khoăn về khả năng kiểm thử liên trình duyệt

Với một mã lọc đơn giản nào đó, bạn có thể đảm bảo rằng chỉ những người dùng có đường dẫn chính xác mới tiếp cận được với thử nghiệm.

Đừng băn khoăn về mức độ thông tin kiểm thử

Bạn có thể bổ sung thông tin kiểm thử sau nếu tính năng đó được công nhận. Việc giám sát tốt quan trọng hơn nhiều so với việc phát triển một nền tảng thử nghiệm.

MỘT VÍ DỤ VỀ KIỂM THỬ A/B

Etsy là một trang web bán hàng thủ công. Etsy sử dụng kiểm thử A/B để đánh giá tất cả các ý tưởng mới và lớn về sản phẩm. Ví dụ, một nhà sản xuất nhận thấy rằng việc tìm kiếm một loại sản phẩm cụ thể trên trang bán hàng của một người nào đó sẽ đem lại kết quả bằng 0, và muốn tìm hiểu xem liệu một tính năng cho phép xuất hiện những mặt hàng tương tự từ trang bán hàng của người khác có giúp tăng doanh thu hay không. Để kiểm thử giả thiết này, nhóm tiến hành một bước thực hiện tính năng rất đơn giản. Họ sử dụng một file cấu hình để xác định phần trăm người dùng tiếp cận với thử nghiệm.

Những người dùng truy cập trang mạng mà thử nghiệm đang được tiến hành sẽ ngẫu nhiên được chuyển hướng tới một nhóm kiểm soát hoặc một nhóm giám sát thử nghiệm dựa trên phần thanh toán thêm trong file cấu hình. Các thử nghiệm đầy rủi ro sẽ chỉ được chú ý bởi một tỷ lệ rất nhỏ phần trăm người dùng. Khi một người dùng được đưa vào một giỏ hàng, họ sẽ ở đó trong suốt các lần truy cập, vì vậy với họ, trang mạng sẽ hiển thị một cách nhất quán.

THẤT BẠI AN TOÀN

Kiểm thử A/B cho phép các nhóm xác định những căng thẳng, những giới hạn hoặc các ngưỡng để tạo ra một thử nghiệm thất bại-an toàn. Nhóm có thể xác định giới hạn kiểm soát của một thông số chủ chốt trước khi kiểm thử để có thể giảm hoặc từ bỏ kiểm thử nếu đã đạt đến giới hạn này (ví dụ, sự chuyển đổi giảm xuống dưới một chỉ số xác định). Xác định, chia sẻ và nhất trí về những giới hạn này với tất cả các bên liên quan trước khi thực hiện thử nghiệm sẽ giúp thiết lập các ranh giới, trong đó nhóm có thể tiến hành thử nghiệm an toàn.

Sau đó, thái độ tiếp theo của người dùng được theo dõi và gom lại thành nhóm. Ví dụ, chúng ta có thể muốn xem có bao nhiêu người đi tiếp đến trang thanh toán. Etsy có một công cụ, được thể hiện trong Hình 9-4, xem xét sự khác biệt trong thái độ đối với những điểm cuối khác nhau và cho thấy khi nào thì nó đạt được con số thống kê ở khoảng tin cậy 95%. Ví dụ, trong mục “site-page count” (đếm trang), phần bôi đậm “+0,26%” cho thấy về thống kê, thử nghiệm đó giúp cải tiến 0,26% việc kiểm soát. Về cơ bản, các thử nghiệm phải thực hiện trong một vài ngày để tạo ra được dữ liệu có ý nghĩa về mặt thống kê.

Việc tạo ra sự thay đổi hơn một vài phần trăm cho một thông số kinh doanh là rất hiếm hoi, và thường có thể được quy theo Định luật Twyman: “Nếu một con số thống kê có vẻ thú vị hoặc bất thường, có lẽ là con số đó sai.”

Hình 9-4. Đánh giá sự thay đổi thái độ của người dùng bằng kiểm thử A/B

Nếu giả thiết đó đã được xác định giá trị, có thể làm nhiều việc hơn để xây dựng tính năng và gia tăng quy mô cho đến khi tính năng đó được đưa đến với tất cả người dùng của trang mạng đó. Làm thay đổi khả năng tiếp cận của 100% người dùng tương đương với việc công khai phát hành tính năng đó. Đây là minh họa quan trọng về sự khác biệt giữa triển khai và phát hành, điều mà chúng ta đã thảo luận trong Chương 8. Etsy luôn tiến hành một số thử nghiệm tại bất cứ thời điểm nào trong quá trình sản xuất. Từ một bảng thông số, bạn có thể thấy thử nghiệm nào được lên kế hoạch, thử nghiệm nào đang thực hiện, và thử nghiệm nào đã hoàn thành. Điều này cho phép mọi người nghiên cứu sâu các thông số hiện thời cho mỗi thử nghiệm, như được thể hiện trong Hình 9-5.

Hình 9-5. Các thử nghiệm đang thực hiện tại Etsy

NHỮNG THAY THẾ CHO KIỂM THỬ A/B

Mặc dù chúng ta dành nhiều thời gian thảo luận về kiểm thử A/B trong chương này, nhưng đây chỉ là một trong rất nhiều kỹ thuật thử nghiệm để thu thập dữ liệu. Các nhà thiết kế trải nghiệm người dùng có nhiều công cụ khác để tiếp nhận phản hồi của người dùng, từ nguyên mẫu có độ thực thấp (lo-fi) tới các phương pháp nghiên cứu dân tộc học như điều tra ngữ cảnh, như được thể hiện trong Hình 9-3. Cuốn Lean UX đã thảo luận một số công cụ này và cách áp dụng chúng trong bối cảnh phát triển định hướng giả thiết.

ĐIỀU KIỆN TIÊN QUYẾT CHO CÁCH TIẾP CẬN THỬ NGHIỆM TRONG PHÁT TRIỂN SẢN PHẨM

Thuyết phục mọi người tập hợp, và sau đó chú ý đến những dữ liệu thực tế từ thử nghiệm, như là kiểm thử A/B, là hoàn toàn chưa đủ. Nhưng một cách tiếp cận khoa học và tập trung vào thử nghiệm trong tạo lập giá trị khách hàng có ý nghĩa đối với cách chúng ta triển khai công việc cũng như cách chúng ta tư duy về giá trị. Dan McKinley, người xây dựng Etsy, chỉ ra rằng việc thử nghiệm không thể bị ngăn chặn trong tiến trình phát triển sản phẩm theo mô hình thác nước. Nếu chúng ta đi đến chặng cuối của một vài tuần (hoặc vài tháng) thực hiện công việc và cố gắng thực hiện một thử nghiệm, rất có khả năng chúng ta sẽ thấy một khối lượng công việc khổng lồ mà chúng ta đã làm hoặc là không có tác dụng gì hoặc làm cho mọi việc còn tồi tệ hơn. Đến khi đó chúng ta sẽ phải bỏ hết vì không có cách nào xác định chính xác tác động của từng thay đổi cụ thể được thực hiện.

Đây sẽ là một quyết định vô cùng đau xót, và trên thực tế nhiều nhóm đã sử dụng “ngụy biện chi phí chìm” bằng cách quan trọng hóa quá mức khoản đầu tư được thực hiện cho đến ngày đưa ra quyết định này. Họ phớt lờ các dữ liệu và tiếp tục triển khai sản phẩm bởi vì việc dừng công việc lại bị coi là thất bại toàn tập trong khi triển khai thành công việc đưa bất cứ điều gì vào sản xuất đều được coi là thành công, miễn là nó đúng thời gian và trong phạm vi ngân sách.

Nếu định tiếp thu triệt để cách tiếp cận thử nghiệm, chúng ta cần thay đổi những gì được coi là kết quả công việc: không chỉ là những ý tưởng được thẩm định mà còn cả những thông tin chúng ta thu được trong tiến trình thực hiện các thử nghiệm. Chúng ta cũng cần thay đổi cách suy nghĩ về việc phát triển các ý tưởng mới; đặc biệt, điều quan trọng là phải làm việc trong các nhóm nhỏ và kiểm thử mọi giả định đằng sau ý tưởng mà chúng ta đang thẩm định. Điều này, đổi lại, đòi hỏi chúng ta phải thực hiện Phân phối Liên tục, như được mô tả trong Chương 8.

Làm việc theo nhóm nhỏ tạo ra dòng – một yếu tố then chốt của Tư duy Tinh gọn. Nhưng những nhóm nhỏ khó có thể thành công, vì những lý do cả về triết lý và kỹ thuật. Một số người có vấn đề với việc thực hiện cách tiếp cận tăng trưởng trong tạo dựng sản phẩm. Một ý kiến phản đối phổ biến đối với cách tiếp cận thử nghiệm là cách này dẫn tới các quyết định tối ưu hóa cục bộ nhưng không tối ưu về tổng thể, làm giảm tính thống nhất chung của sản phẩm và phá hoại hình ảnh đẹp đẽ và toàn diện của sản phẩm với hàng nghìn các cuộc kiểm thử A/B.

Mặc dù chắc chắn là có thể kết thúc với một sản phẩm xấu xí và quá phức tạp nếu các nhóm không thực hiện cách tiếp cận toàn diện với trải nghiệm người dùng, nhưng đây không phải là kết quả tất yếu của kiểm thử A/B. Việc thử nghiệm này không được coi là để thay thế cho một tầm nhìn sản phẩm. Trên thực tế, nó giúp bạn nhanh chóng phát triển chiến lược và tầm nhìn nhằm phản ứng trước những dữ liệu thực tế từ các khách hàng sử dụng sản phẩm của bạn trong môi trường của họ. Kiểm thử A/B sẽ không hiệu quả nếu thiếu một tầm nhìn và chiến lược. Các nhà quản lý, thiết kế sản phẩm và các kỹ sư cần phối hợp và áp dụng những bài học về tư duy thiết kế để có tầm nhìn lâu dài về nhu cầu của người dùng cũng như xây dựng định hướng cho sản phẩm.

BÍ QUYẾT

Tư duy thiết kế là gì?

Tim Brown, CEO kiêm Chủ tịch IDEO, một trong những nhân vật quan trọng khởi xướng tư duy thiết kế, nói rằng: “Là một loại tư duy, nhìn chung được coi là khả năng kết hợp sự thấu cảm trong bối cảnh một vấn đề, tính sáng tạo trong tìm kiếm hiểu biết và giải pháp và tính lý trí để phân tích và đưa giải pháp vào bối cảnh.” Chúng ta thảo luận sâu hơn về tư duy thiết kế và UX tinh gọn trong Chương 4.

Có hai trở ngại khác đối với việc áp dụng cách tiếp cận thử nghiệm trong phát triển sản phẩm. Thứ nhất, việc thiết kế các thử nghiệm rất khó khăn: chúng ta không được để chúng cản trở nhau, áp dụng những cảnh báo để phát hiện những diễn biến bất thường và thiết kế chúng nhằm tạo ra kết quả có giá trị. Đồng thời, chúng ta muốn giảm thiểu số lượng công việc phải làm mà vẫn thu thập những dữ liệu quan trọng về mặt thống kê.

Thứ hai, việc thực hiện cách tiếp cận khoa học phát triển sản phẩm và khách hàng đòi hỏi phải có sự phối hợp chặt chẽ giữa công nhân, nhà thiết kế và nhân viên kỹ thuật trong toàn bộ vòng đời của mỗi sản phẩm. Đây là một sự thay đổi văn hóa lớn cho nhiều doanh nghiệp, nơi mà đội ngũ kỹ thuật thường không đóng góp nhiều cho tiến trình thiết kế nói chung.

Những trở ngại này là lý do tại sao chúng tôi tích cực khuyến cáo mọi người không chấp nhận những công cụ được thảo luận trong chương này nếu trước đó không thiết lập những nền tảng được mô tả trong những chương đầu của Phần III.

SỰ ĐỔI MỚI ĐÒI HỎI PHẢI CÓ VĂN HÓA THỬ NGHIỆM

Greg Linden, người phát triển hệ thống khuyến nghị đầu tiên của Amazon, đặt giả thiết rằng việc đưa ra những khuyến nghị cá nhân tại thời điểm thanh toán có thể thuyết phục mọi người hứng thú và mua thêm – tương tự như giá để đồ ở lối thanh toán tại một cửa hàng tạp hóa, nhưng phù hợp hóa với từng khách hàng bởi một thuật toán. Tuy nhiên, một phó chủ tịch cấp cao lại tin rằng điều đó sẽ làm khách hàng sao nhãng việc thanh toán. Greg bị cấm triển khai thêm bất cứ việc gì liên quan đến tính năng này.

Lindon đã không tuân lệnh vị phó chủ tịch đó và thực hiện một cuộc kiểm thử A/B. Kết quả cho thấy sự tăng doanh thu rõ rệt khi mọi người nhận được những khuyến nghị được cá nhân hóa tại trang thanh toán mà tính năng đó được tạo ra và phát hành khá khẩn cấp.

Bạn có chấp nhận được việc một kỹ sư ở công ty bạn thúc đẩy thực hiện một cuộc kiểm thử A/B khi bị một nhà quản lý cấp cao phản đối? Nếu các dữ liệu thử nghiệm chứng tỏ rằng nhà quản lý đó sai, thì có chắc chắn là tính năng đó sẽ được lựa chọn chứ không phải là bị vùi dập hay không? Linden viết: “Sáng tạo phải xuất phát từ mọi nơi. Dù bạn là một thực tập sinh mùa hè hay một vị giám đốc công nghệ, bất kỳ ý tưởng hay nào cũng đều phải có khả năng tìm kiếm một cuộc kiểm thử mục tiêu, tốt nhất là một cuộc kiểm thử thể hiện rõ ý tưởng với khách hàng thực. Mọi người phải có khả năng thử nghiệm, học hỏi và tái lặp. Chức vụ, sự vâng lệnh và truyền thống không nên ảnh hưởng đến việc đó. Để có thể đổi mới mạnh mẽ, việc đánh giá phải mang tính quyết định.”

Một văn hóa dựa trên đánh giá và thử nghiệm không trái ngược với các ý tưởng táo bạo, cách tư duy khác biệt và phép loại suy⁸. Trên thực tế, nó tạo cơ sở cho mọi người theo đuổi các ý tưởng điên rồ của họ bằng cách tạo thuận lợi cho việc thu thập dữ liệu thực để chứng minh những ý tưởng tốt và bác bỏ những ý tưởng tệ hại. Nếu không có khả năng thực hiện những thử nghiệm rẻ và an toàn khi thất bại, thì những ý tưởng như thế sẽ bị chà đạp bởi một HiPPO sắp hết thời hoặc một quyết định theo cơ chế hội đồng.

8 Abductive reasoning – là một dạng suy luận lô-gic bắt đầu bằng một quan sát, sau đó tìm cách lý giải đơn giản và chắc chắn nhất. (ND)

Một trong những thách thức phổ biến nhất thường gặp phải trong phát triển phần mềm là việc các nhóm, các nhà quản lý sản phẩm và các tổ chức tập trung nỗ lực vào quản lý chi phí chứ không phải giá trị. Điều này thể hiện rõ trong những nỗ lực không cần thiết cho các hoạt động không-tạo-thêm-giá-trị như là phân tích, đánh giá trước các chi tiết, chú trọng quản lý quy mô và rà soát kho tồn đọng⁹. Những dấu hiệu này là kết quả của việc tập trung vào tối đa hóa việc huy động (duy trì cho các nhân viên quý báu của chúng ta luôn bận rộn) và đầu ra (tính toán sản phẩm công việc của họ) thay vì tập trung vào kết quả, giảm thiểu đầu ra cần thiết để đạt được kết quả đó và giảm thời lượng sản xuất để nhanh chóng nhận được phản hồi về các quyết định của chúng ta.

⁹ Rà soát kho tồn đọng (backlog grooming): Là quá trình rà soát liên tục các hạng mục sản phẩm tồn đọng và kiểm tra xem chúng có được ưu tiên/chuẩn bị đúng mức không. (BTV)

KẾT LUẬN

Nhiều ý tưởng – ngay cả những ý tưởng rõ ràng là hay – lại không đem lại giá trị hoặc chỉ đem lại giá trị tiêu cực cho người dùng. Bằng cách tập trung vào kết quả mà chúng ta mong muốn đạt được chứ không phải là các giải pháp hay tính năng, chúng ta có thể phân biệt những gì mà chúng ta đang cố gắng làm với các biện pháp khả dĩ để làm chúng. Khi đó, theo Yêu cầu Nhiệm vụ, các nhóm có thể thực hiện nghiên cứu người dùng (bao gồm các thử nghiệm trực tuyến có độ rủi ro thấp, thất bại-an toàn) để quyết định những gì thực sự cung cấp giá trị cho khách hàng – và cho tổ chức của chúng ta.

Bằng cách kết hợp sơ đồ tác động và nghiên cứu người dùng với khuôn khổ Kata Cải tiến được trình bày trong Chương 6, chúng ta có thể đánh giá phân phối phần mềm linh hoạt, kết hợp nó với tư duy thiết kế và một cách tiếp cận thử nghiệm trong phát triển sản phẩm. Điều này cho phép chúng ta nhanh chóng khám phá, phát triển và phân phối các giải pháp giá trị cao, chất lượng cao cho người dùng ở quy mô phù hợp, khai thác được kỹ năng và sự khéo léo của mọi người trong tổ chức.

Câu hỏi dành cho độc giả:

◆ Điều gì xảy ra ở tổ chức của bạn khi một số lượng đáng kể những nỗ lực được đầu tư vào một ý tưởng mà hóa ra lại cung cấp rất ít giá trị cho người dùng hay tổ chức, hoặc thậm chí làm cho mọi việc trở nên tồi tệ hơn?

◆ Bạn có đo lường được những kết quả mà khách hàng mong đợi đối với các tính năng mà bạn đang xây dựng không? Bạn có cách nào để đo lường những kết quả thực tế?

◆ Bạn đang thực hiện loại nghiên cứu người dùng nào đối với các nguyên mẫu trước khi cho lưu hành rộng rãi? Làm cách nào bạn có thể nhận được phản hồi đó nhanh hơn và rẻ hơn?

◆ Lần cuối cùng bạn quan sát thấy sản phẩm của mình được sử

dụng hoặc được đề cập đến trong đời thường là khi nào?

◆ Bạn có thể tìm được biện pháp chi phí thấp để kiểm thử giá trị của phần việc tiếp theo trong danh mục công việc tồn đọng của bạn không?

Chương 10Thực thi Yêu cầu Nhiệm vụ

Càng gắn kết thì bạn càng có thể giao cho nhân viên nhiều quyền tự chủ hơn. Cái này bổ trợ cho cái kia.

− STEPHEN BUNGAY

Những nhà quản lý tài ba nhất luôn biết cách đạt được kết quả vĩ đại bằng việc thiết lập bối cảnh phù hợp thay vì cố gắng kiểm soát nhân viên của mình.

− REED HASTINGS

Trong bài phát biểu năm 2009 về văn hóa Netflix, Tự do và Trách nhiệm, CEO Reed Hastings mô tả động lực phổ biến của nhiều tổ chức đang phát triển. Khi các tổ chức lớn hơn, chúng trở nên phức tạp hơn xét về các hệ thống mà chúng đang phát triển và vận hành, môi trường kinh doanh mà chúng hoạt động và khả năng “hoàn thành mọi công việc”. Cuối cùng, công việc kinh doanh trở nên quá phức tạp và không thể điều hành mà không theo thể thức nhất định. Thế là các quy trình chính thức được đưa ra để ngăn không cho tổ chức rơi vào hỗn loạn. Các quy trình này giúp tạo ra quy chuẩn nhất định nhưng lại làm chậm tốc độ và gần như không thể làm được gì để ngăn ngừa những kết quả xấu xuất phát từ những sự kiện không thể quản lý bằng quy trình (chẳng hạn như những công việc được thực hiện theo kế hoạch nhưng không đem lại giá trị khách hàng).

Quản lý thông qua kiểm soát quy trình có thể chấp nhận được trong một số tình huống nhất định trong các tiến trình sản xuất (loại hệ thống mà Six Sigma hoạt động có hiệu quả) nhưng không thể chấp nhận trong phát triển sản phẩm bởi khi đó, nó sẽ dẫn đến việc tối ưu hóa hiệu năng và tính dự báo thay vì khả năng đổi mới và thích ứng với những điều kiện thay đổi. Geoff Nicholson, người phát minh ra giấy ghi chú, tuyên bố rằng việc thừa nhận Six Sigma của hãng 3M theo chỉ đạo của CEO James McNemey (trước đây là của GE và bây giờ là Boeing) đã “giết chết sự đổi mới”. Các quy trình dựa trên nguyên tắc và thông lệ cũng kìm hãm sự cải tiến không ngừng nếu những người vận hành tiến trình đó không được phép sửa đổi chúng. Cuối cùng, sự ỷ lại vào các quy trình có xu hướng loại khỏi hệ thống những người dám nghĩ, dám chấp nhận rủi ro và dám tiến hành những thử nghiệm thất bại-an toàn. Những người này có xu hướng cảm thấy ngột ngạt trong môi trường quá chú trọng về quy trình – nhưng họ chính là nhân tố thúc đẩy văn hóa đổi mới.

Tương tự như vậy, khi các tổ chức phát triển, các hệ thống mà họ xây dựng và vận hành cũng gia tăng độ phức tạp. Để nhanh chóng đưa ra thị trường các tính năng mới, chúng ta thường đánh đổi chất lượng để lấy tốc độ lưu thông cao hơn. Đây là một quyết định nhạy bén và hợp lý. Nhưng ở khía cạnh nào đó, mức độ phức tạp của hệ thống trở thành yếu tố hạn chế khả năng tạo ra công việc mới. Điều đó có nghĩa là chúng ta đang lao đầu vào tường. Nhiều doanh nghiệp có hàng nghìn dịch vụ sản xuất, trong đó có các hệ thống chủ chốt vận hành trên nền tảng lỗi thời. Những hệ thống này thường kết nối với nhau theo nhiều cách dẫn đến việc rất khó thay đổi bất kỳ một bộ phận nào trong hệ thống mà không làm thay đổi những bộ phận khác. Đây là lực cản đáng kể đối với khả năng đổi mới một cách quy mô của doanh nghiệp.

Những quan ngại về tổ chức và kết cấu này thường là những rào cản lớn nhất đối với việc thực thi chiến lược phát triển quy mô nhanh chóng dựa trên các nguyên tắc Yêu cầu Nhiệm vụ được đề cập trong Chương 1. Chúng tôi sẽ bắt đầu bằng việc giới thiệu một bậc thầy về thực thi chiến lược quản lý tính phức tạp của tổ chức và hệ thống trong kỷ nguyên mạng: Amazon. Sau đó, chúng tôi sẽ trình bày các nguyên tắc tổ chức, kết cấu và lãnh đạo nhằm giúp các tổ chức phát triển thành công.

GIẢI PHÁP TĂNG TRƯỞNG CỦA AMAZON

Năm 2001, Amazon đã gặp một vấn đề: Phần mềm “Quả bóng bùn lớn” (Big ball of mud¹) cồng kềnh và đồ sộ vận hành trang mạng của họ, một hệ thống được gọi là Obidos, không thể mở rộng quy mô. Nguyên nhân hạn chế là do cơ sở dữ liệu. CEO Jeff Bezos đã biến vấn đề này thành cơ hội.

¹ Một hệ thống phần mềm thiếu kết cấu rõ ràng. (ND)

Ông muốn Amazon trở thành nền tảng để thúc đẩy các công việc kinh doanh khác với mục tiêu tối thượng là đáp ứng tốt hơn các nhu cầu khách hàng. Với suy nghĩ như vậy, ông gửi một bản ghi nhớ cho đội ngũ kỹ thuật để chỉ đạo họ xây dựng một kiến trúc định hướng dịch vụ. Steve Yegge tóm lược nội dung này như sau:

1. Tất cả các nhóm từ nay sẽ hiển thị dữ liệu và chức năng của họ thông qua giao diện dịch vụ.

2. Các nhóm phải giao tiếp với nhau thông qua các giao diện này.

3. Sẽ không còn loại hình giao tiếp liên quy trình nào khác: không trực tiếp kết nối, không trực tiếp đọc kho dữ liệu của nhóm khác, không sử dụng mô hình dùng chung bộ nhớ, không sử dụng cửa sau… Hình thức giao tiếp duy nhất được phép là thông qua các cuộc gọi giao diện dịch vụ trên mạng.

4. Không quan tâm các nhóm sử dụng công nghệ gì. Các giao thức HTTP, Corbra, Pubsub, Tùy chỉnh – đều được. Bezos không quan tâm.

5. Tất cả các giao diện dịch vụ, không có ngoại lệ, ngay từ đầu đều phải được thiết kế để có khả năng mở rộng. Tức là, nhóm phải lập kế hoạch và thiết kế để có thể thể hiện giao diện với lập trình viên ở thế giới bên ngoài. Không có ngoại lệ.

6. Bất kỳ ai không làm như vậy đều sẽ bị sa thải.

Bezos thuê Rick Dalzell, nguyên là một lính biệt kích từng học tại Học viện Quân sự West Point, triển khai những nguyên tắc này. Cùng với đó, Bezos chỉ đạo tiến hành một thay đổi quan trọng khác: mỗi dịch vụ sẽ được một nhóm liên chức năng sở hữu, xây dựng và điều hành trong suốt vòng đời của mình. Werner Vogels, Giám đốc Công nghệ của Amazon, tuyên bố: “Bạn xây dựng nó, bạn vận hành nó.” Quy định này, cùng với nguyên tắc rằng tất cả các giao diện dịch vụ được thiết kế để có thể mở rộng, đã đem lại một số kết quả quan trọng. Vogels chỉ rõ, cách tổ chức nhóm theo kiểu này “làm cho các lập trình viên tiếp xúc với các hoạt động thường ngày của phần mềm. Nó cũng giúp họ liên hệ hằng ngày với khách hàng. Vòng lặp phản hồi này của khách hàng thực sự cần thiết để nâng cao chất lượng dịch vụ”.

Như vậy, nhóm nào cũng tham gia có hiệu quả vào việc phát triển sản phẩm – kể cả những người làm ở bộ phận hạ tầng, trong đó có bộ phận Amazon Web Services², như là EC2³ chẳng hạn. Rất khó để nhấn mạnh quá mức đến tầm quan trọng của sự chuyển đổi từ một mô hình đầu tư và phân phối dựa trên dự án sang mô hình dựa trên phát triển sản phẩm.

² AWS − Dịch vụ điện toán đám mây. (ND)

³ EC2 − Amazon Elastic Compute Cloud (Amazon EC2) là một dịch vụ mạng cung cấp khả năng tính toán an toàn và có thể thay đổi kích thước trong đám mây. Nó được thiết kế để làm cho điện toán đám mây quy mô mạng dễ dàng hơn cho các lập trình viên. (ND)

Một trong những vấn đề lớn nhất khi các tổ chức lớn mạnh lên là việc duy trì giao tiếp hiệu quả giữa các cá nhân và giữa các nhóm với nhau. Khi bạn chuyển nhân viên đến một tầng khác, một tòa nhà khác hay một khu vực có múi giờ khác thì các kênh giao tiếp trở nên vô cùng hạn chế và vì vậy rất khó để duy trì hiểu biết chung, sự tin cậy và hiệu quả hợp tác. Để kiểm soát vấn đề này, Amazon quy định tất cả các nhóm đều phải tuân thủ luật “nhóm hai bánh pizza” (two-pizza team: 2PT): các nhóm chỉ nên đủ nhỏ để ăn vừa hết hai chiếc bánh pizza, thường khoảng từ 5-10 người.

Quy định hạn chế về quy mô này có bốn hiệu ứng quan trọng:

1. Nó bảo đảm nhóm có hiểu biết chung và rõ ràng về hệ thống mà họ đang làm việc. Khi các nhóm trở nên lớn hơn, khối lượng giao tiếp cần thiết để mọi người hiểu được điều gì đang diễn ra cũng phải gia tăng mạnh mẽ.

2. Nó hạn chế tốc độ phát triển sản phẩm hoặc dịch vụ đang được nghiên cứu. Bằng việc giới hạn quy mô nhóm, chúng ta giới hạn tốc độ phát triển hệ thống của các nhóm. Nó cũng giúp bảo đảm cho nhóm duy trì được hiểu biết chung về hệ thống.

3. Có lẽ điều quan trọng nhất là điều đó giúp phi tập trung hóa quyền lực và tạo dựng quyền tự chủ theo Yêu cầu Nhiệm vụ. Các nhóm “2PT” càng có khả năng tự chủ càng tốt. Người đứng đầu nhóm, qua làm việc với nhóm điều hành, sẽ quyết định thông số kinh doanh chính mà nhóm phải chịu trách nhiệm, được gọi là chức năng mục tiêu. Thông số này sẽ trở thành tiêu chí đánh giá chung cho các thử nghiệm của nhóm. Khi đó, nhóm có thể tự chủ hành động để tối đa hóa thông số đó bằng cách áp dụng những kỹ thuật mà chúng tôi đã mô tả trong Chương 9.

4. Lãnh đạo một nhóm 2PT là biện pháp để các nhân viên tiếp thu được kinh nghiệm lãnh đạo nào đó trong một môi trường mà sự thất bại không gây ra những hậu quả khủng khiếp. Điều đó “giúp công ty thu hút và giữ chân được các tài năng kinh doanh”.

Một thành tố quan trọng trong chiến lược của Amazon là mối liên kết giữa kiến trúc doanh nghiệp của một nhóm 2PT và cách tiếp cận kiến trúc của một kiến trúc theo định hướng dịch vụ.

GIỚI THIỆU SƠ LƯỢC VỀ CÁC KIẾN TRÚC ĐỊNH HƯỚNG DỊCH VỤ

Nguyên tắc chủ chốt của một kiến trúc định hướng dịch vụ (SOA) là phân tách các hệ thống thành các thành tố hoặc dịch vụ. Mỗi thành tố hay dịch vụ cung cấp một giao diện (được gọi là Giao diện Lập trình Ứng dụng – API) để các bộ phận khác có thể liên lạc với nó. Các bộ phận khác của hệ thống – và các nhóm tạo ra chúng không cần thiết phải biết chi tiết các bộ phận hoặc dịch vụ mà họ đang sử dụng được xây dựng như thế nào. Thay vào đó, họ chỉ cần biết đến giao diện liên lạc. Điều này cũng có nghĩa rằng không cần thiết phải có nhiều giao tiếp giữa các nhóm sử dụng một dịch vụ hay một thành tố với nhóm xây dựng và duy trì nó. Thực vậy, nếu API được thiết kế đủ tốt và có đủ thông tin thì không cần phải có giao tiếp.

Bất kỳ hệ thống nào cũng có thể được phân tách theo nhiều cách khác nhau. Phân tách hệ thống là một nghệ thuật – và khi hệ thống trở lên lớn hơn thì biện pháp phân tách lý tưởng cũng phải thay đổi. Có hai quy tắc kiến trúc ngón tay cái khi phân tách các hệ thống. Thứ nhất, phải bảo đảm rằng việc bổ sung một tính năng mới sẽ chỉ làm thay đổi một dịch vụ hoặc thành tố ở một thời điểm cụ thể. Điều này giúp giảm số lượng người rời bỏ giao diện. Thứ hai, phải tránh các giao tiếp vớ vẩn hoặc chỉ để “tán gẫu” giữa các dịch vụ. Các dịch vụ chỉ để tán gẫu thường kém phát triển và khó đánh giá cho mục đích kiểm thử.

Tất cả các hệ thống được thiết kế tốt đều được phân nhỏ thành các thành tố. Điều tạo nên sự khác biệt của một kiến trúc định hướng dịch vụ là các thành tố của nó có thể được triển khai sản xuất một cách độc lập. Không còn tình trạng “vụ nổ lớn” (big bang), tức là tất cả các thành tố của hệ thống đồng loạt ra mắt: mỗi dịch vụ có lộ trình phát hành riêng. Nguyên tắc quan trọng nhất cần phải tuân thủ là: nhóm quản lý một dịch vụ phải bảo đảm được rằng khách hàng sẽ không tuyệt giao với dịch vụ khi phiên bản mới được đưa ra.

Để tránh đầu tư quá mức cho liên lạc dẫn đến suy giảm năng suất khi phát triển phần mềm, Amazon đã áp dụng một trong những luật phát triển phần mềm quan trọng nhất – Luật Conway: “Một công ty thiết kế hệ thống thế nào cũng sẽ làm ra những thiết kế giống y hệt với thiết kế hệ thống của chính công ty họ.” Một phương pháp để áp dụng Luật Conway là gắn các biên API với các biên nhóm. Bằng cách này, chúng ta có thể phân bố các nhóm trên toàn thế giới. Miễn là mỗi dịch vụ đều do một nhóm đơn lẻ, làm việc cùng một nơi, có năng lực tự chủ và liên chức năng phát triển và vận hành, thì việc giao tiếp nhiều giữa các nhóm là không còn cần thiết.

Các tổ chức thường tìm cách chống lại Luật Conway. Một minh chứng phổ biến là việc căn cứ vào chức năng để phân tách các nhóm, ví dụ như bố trí các kỹ sư và nhân viên kiểm thử ở các địa điểm khác nhau (hoặc, thậm chí còn tồi tệ hơn, là thuê nhân viên kiểm thử nước ngoài). Một minh chứng khác, đầu vào của một sản phẩm do một nhóm phát triển, triết lý kinh doanh do nhóm thứ hai hình thành và phần cơ sở dữ liệu lại do nhóm thứ ba xây dựng. Vì bất kỳ tính năng mới nào cũng đều đòi hỏi cả ba nhóm phải thay đổi, nên chúng ta cần các nhóm này phải giao tiếp nhiều, điều sẽ bị ảnh hưởng nghiêm trọng nếu họ ở các địa điểm riêng biệt. Phân tách nhóm theo chức năng hoặc theo lớp kiến trúc thường dẫn đến rất nhiều việc phải làm lại, nhiều những bất đồng về chi tiết, kiểm soát kém và người này lười nhác trông chờ người khác.

Giải pháp của Amazon đương nhiên không phải là cách duy nhất để tăng tốc độ với quy mô phù hợp, nhưng nó cho thấy có sự gắn kết quan trọng giữa các cơ cấu giao tiếp, phương pháp lãnh đạo và kiến trúc hệ thống.

TĂNG TỐC VỚI QUY MÔ PHÙ HỢP THÔNG QUA YÊU CẦU NHIỆM VỤ

Khi các tổ chức phát triển, các quy trình không chính thống và các kênh liên lạc ngày càng trở nên kém hiệu quả trong việc đem lại kết quả ở cấp độ hệ thống mà chúng ta mong muốn. Thực vậy, tốc độ tăng trưởng nhanh dễ khiến mọi người không giám sát được các kết quả ở cấp độ hệ thống. Khi các tổ chức phát triển, chúng chuyển sang những lĩnh vực phức tạp hơn. Đặc biệt, hai đặc tính của hệ thống thích nghi phức tạp bắt đầu có vấn đề.

Đầu tiên, không có viễn cảnh ưu tiên để từ đó mọi người có thể hiểu được toàn bộ hệ thống, ngay cả văn phòng của CEO.

Thứ hai, mọi người chỉ có thể hiểu được một phần nhỏ của toàn bộ hệ thống với mức độ phụ thuộc vào thông tin và bối cảnh mà họ có.

Vì vậy, nếu không cẩn trọng với cách phát triển hệ thống, chúng ta sẽ kết thúc với một hệ thống mà ở đó mọi người tối ưu hóa cái họ thấy và những phản hồi họ nhận được, vốn ít nhiều bị ảnh hưởng bởi những người họ tương tác hằng ngày. Theo đó, mỗi bộ phận đều tối ưu hóa vì lợi ích của mình – không phải bởi mọi người ngu dốt hoặc xấu tính mà đơn giản là vì họ không thấy rõ những hiệu ứng từ hành động của họ trong một tổ chức lớn hơn. Một giản đồ về một doanh nghiệp được kết cấu theo kiểu truyền thống được minh họa trong Hình 10-1.

Hình 10-1: Ví dụ về một tổ chức doanh nghiệp truyền thống

Chìa khóa để tăng tốc với quy mô phù hợp là phải xây dựng được nhiều nhóm nhỏ, phi tập trung hóa và có tính tự chủ cao dựa theo mô hình Yêu cầu Nhiệm vụ được mô tả trong Chương 1. Tại các tổ chức phân quyền thực thụ, chúng ta tuân thủ nguyên tắc phụ trợ (subsidiary): mặc định là các quyết định cần được đưa ra bởi những người trực tiếp chịu ảnh hưởng từ những quyết định này. Các cấp cao hơn của bộ máy chỉ nên thực hiện các nhiệm vụ không thể được thực hiện một cách hiệu quả ở cấp bộ phận – tức là, thẩm quyền của các cấp cao hơn trong bộ máy chỉ nên mang tính phụ trợ cho cấp bộ phận. Một số tổ chức lớn và thành công đã tuân thủ nguyên tắc này trong nhiều năm – chẳng hạn như Công ty Gore, Hàng không Southwest Airline và Ngân hàng Thụy Điển Handelsbanken. Tất cả các doanh nghiệp này đều liên tục đạt hiệu năng cao hơn mức trung bình trongcác thị trường của họ.

Đầu tiên, chúng ta phải xác định được đơn vị tổ chức cơ bản, một nhóm gồm tối đa 10 người (theo luật “nhóm hai bánh pizza” của Amazon). Khi nhóm có hơn 10 người, rất khó để quản lý động lực và sự phối hợp trong nhóm; khó có thể đưa ra những quyết định có mức đồng thuận cao và khó thống nhất được nhận thức chung trong nhóm về tình hình hoạt động.

Trong môi trường doanh nghiệp, các nhóm thường xuyên phối hợp để đạt được các mục tiêu ở cấp độ tổng quan; các sản phẩm và dịch vụ lớn hơn sẽ cần nhiều nhóm, có lẽ cả các nhân viên tận tụy phụ trách tiếp thị và bảo đảm. Theo Reed Hasting, mục đích của chúng ta là phải tạo ra các nhóm có khả năng phối hợp tốt nhưng kết hợp một cách lỏng lẻo. Chúng ta cần đảm bảo rằng các nhóm phối hợp được với nhau bằng việc sử dụng Kata Cải tiến như đã được đề cập trong Chương 6 và Chương 9, đó là, bằng cách thực hiện các vòng lặp ở cấp độ tổng quan với các điều kiện mục tiêu xác định và buộc các nhóm phải phối hợp để tìm phương cách đạt được các mục tiêu đó.

Dưới đây là một số chiến lược mà các doanh nghiệp đã áp dụng thành công nhằm trao quyền tự chủ cho các nhóm riêng rẽ:

Giao cho các nhóm các công cụ và thẩm quyền thúc đẩy sự thay đổi trong sản xuất

Ở các công ty như Amazon, Netflix và Etsy, trong nhiều trường hợp, các nhóm không cần phải báo cáo để một ban cố vấn phê duyệt những thay đổi trước khi triển khai chúng vào sản xuất. Trên thực tế, tại Etsy, thẩm quyền này không chỉ được dành cho các nhóm mà còn cho cả các kỹ sư. Công ty mong muốn các kỹ sư tham vấn lẫn nhau trước khi thúc đẩy những thay đổi, và một vài loại thay đổi có độ rủi ro cao (chẳng hạn như thay đổi về cơ sở dữ liệu hoặc về môi trường dữ liệu chủ thẻ PCI-DSS – PCI-DSS CardholderData Environment) được quản lý ngoài dải băng⁴. Nhưng nói chung, công ty mong muốn các kỹ sư thực hiện kiểm thử tự động và tham vấn những người khác trong nhóm để xác định rủi ro của mỗi sự thay đổi. Công ty tin rằng họ sẽ hành động một cách phù hợp dựa trên những thông tin này. ITIL hỗ trợ cho khái niệm này dưới dạng những thay đổi tiêu chuẩn.

4 Ngoài dải băng (out-of-band): Là dữ liệu được truyền qua một dòng dữ liệu độc lập với dữ liệu chính trong dải băng. (BTV)

Tất cả những thay đổi “ra mắt tối” (tạo nền tảng cho kiểm thử A/B) cần được xem là những thay đổi tiêu chuẩn. Đổi lại, điều quan trọng là các nhóm phải có trách nhiệm hỗ trợ những thay đổi của họ; để hiểu sâu hơn về vấn đề này, mời độc giả xem Chương 14.

Đảm bảo rằng các nhóm đều có được người họ cần để thiết kế, vận hành và phát triển các thử nghiệm

Mỗi nhóm cần có thẩm quyền và kỹ năng cần thiết để đưa ra một giả thiết, thiết kế một thử nghiệm, đưa một kiểm thử A/B vào quá trình sản xuất và sau đó thu thập dữ liệu. Vì các nhóm đều nhỏ nên điều này thường có nghĩa là nhóm liên chức năng với nhiều người khác nhau: Một số chuyên gia chuyên sâu về một hoặc hai lĩnh vực (đôi khi được gọi là những người hình chữ T⁵), cùng với đội ngũ chuyên gia như một nhà quản lý cơ sở dữ liệu, một chuyên gia UX và một chuyên gia về miền. Điều này không ngăn cản việc tổ chức các nhóm tập trung các chuyên gia có khả năng hỗ trợ các nhóm sản phẩm theo yêu cầu.

⁵ Hình chữ T (T-shaped): Thuật ngữ trong lĩnh vực nhân sự, chỉ những người vừa có kiến thức sâu về chuyên môn vừa có khả năng kết nối với nhiều lĩnh vực. (BTV)

Đảm bảo rằng các nhóm có quyền lựa chọn chuỗi công cụ lập trình của riêng mình

Ủy thác một chuỗi công cụ cho một nhóm sử dụng là minh chứng về việc tối ưu hóa để đáp ứng nhu cầu về cung ứng và tài chính chứ không phải về nhân lực. Các nhóm phải được tự do lựa chọn các công cụ riêng cho mình. Ngoại lệ đối với việc này là nền tảng công nghệ được sử dụng để vận hành các dịch vụ trong quá trình sản xuất. Lý tưởng nhất là nhóm sẽ sử dụng một dịch vụ nền hoặc dịch vụ hạ tầng (PaaS hoặc IaaS) do bộ phận IT nội bộ hoặc một đối tác bên ngoài cung cấp, cho phép các nhóm tự triển khai vào môi trường kiểm thử và môi trường vận hành (khi phù hợp) theo nhu cầu thông qua một API (chứ không phải thông qua một hệ thống báo cáo hoặc thư điện tử). Nếu không có hệ thống nào như thế tồn tại hoặc hệ thống không phù hợp thì nhóm cần được phép lựa chọn nền tảng riêng cho mình – nhưng phải sẵn sàng đáp ứng các ràng buộc pháp lý khi cần và gánh chịu chi phí hỗ trợ hệ thống trong quá trình sản xuất. Chúng tôi sẽ bàn sâu hơn về chủ đề này tại Chương 14.

Đảm bảo rằng các nhóm không yêu cầu phê chuẩn ngân sách thực hiện thử nghiệm

Các kỹ thuật được mô tả trong cuốn sách này giúp việc tiến hành các thử nghiệm rất rẻ, vì vậy việc cấp vốn không phải là trở ngại đối với việc kiểm thử các ý tưởng mới. Các nhóm không nên yêu cầu phải được phê chuẩn thì mới chi tiêu ở một mức giới hạn nào đó (chẳng hạn, mức giới hạn cho mỗi nhiệm vụ và mỗi tháng).

Đảm bảo rằng các nhà lãnh đạo tập trung vào thực thi Yêu cầu Nhiệm vụ

Trong một tổ chức ngày càng phát triển, các lãnh đạo phải liên tục nỗ lực đơn giản hóa các quy trình và tính phức tạp trong kinh doanh, gia tăng hiệu quả, quyền tự chủ và năng lực của các bộ phận nhỏ nhất và xây dựng các nhà lãnh đạo mới trong các bộ phận này.

Một ví dụ về phương pháp này được thể hiện trong Hình 10-2. Đối với các sản phẩm được cài đặt bởi người dùng, các ứng dụng di động và các hệ thống nhúng thì PaaS/IaaS được sử dụng để kiểm thử các mục đích, nhưng tiến trình phát hành được thực hiện dựa trên nhu cầu chứ không liên tục. Hãy lưu ý rằng kiến trúc này không đòi hỏi phải thay đổi người lãnh đạo. Mọi người vẫn có thể hoạt động theo thứ tự chức năng truyền thống (chẳng hạn, các nhân viên kiểm thử báo cáo Giám đốc Kiểm thử) ngay cả nếu như họ làm việc trong các nhóm liên chức năng trên cơ sở thường nhật. Các doanh nghiệp thường lãng phí rất nhiều thời gian vào các hoạt động tái tổ chức không cần thiết và gây hại, trong khi họ sẽ làm tốt hơn chỉ đơn giản bằng cách yêu cầu những người làm việc về cùng một sản phẩm hoặc dịch vụ ngồi với nhau trong cùng phòng (hoặc cùng tầng đối với các sản phẩm lớn hơn).

Hình 10-2. Các nhóm sản phẩm làm việc cùng nhau với một lớp dịch vụ để tiến hành triển khai

CẢNH BÁO

Bảo đảm việc khen thưởng phải gắn với thái độ được kỳ vọng

Mặc dù không cần thiết phải đưa ra các cấu trúc để thể hiện cơ cấu tổ chức của nhóm, nhưng việc quản lý lỏng lẻo dễ phá hoại các hoạt động phối hợp khi dành sự khen thưởng cho những người có hành vi tối ưu hóa chức năng của họ nhưng lại ảnh hưởng đến hiệu quả khách hàng hoặc các mục đích lớn hơn của tổ chức. Các ví dụ về việc này bao gồm việc thưởng cho các lập trình viên vì những tính năng đã được lập trình hoàn thiện nhưng chưa sẵn sàng đưa vào vận hành hoặc thưởng cho các nhân viên kiểm thử vì số lượng lỗi mà họ phát hiện ra. Nói chung, việc thưởng nhân viên vì sản lượng chứ không phải vì kết quả chung của toàn hệ thống sẽ dẫn đến rối loạn chức năng và trong bất kỳ trường hợp nào thì việc khen thưởng bằng tiền hoặc phần thưởng đều dẫn đến sự suy giảm hiệu năng trong môi trường lao động tri thức. Chúng ta bàn chi tiết hơn về chủ đề khích lệ và văn hóa tưởng thưởng ở Chương 1 và Chương 11.

Sẽ có tính kinh tế hơn khi tạo dựng các nhóm nhỏ và tự chủ và cho phép các nhân viên làm việc theo từng nhóm nhỏ. Khi sự kết hợp các nhân viên được thực hiện đúng, nó sẽ đem lại một vài lợi ích quan trọng:

Học hỏi nhanh hơn, dịch vụ khách hàng được cải thiện, tốn ít thời gian hơn cho những công việc không gia tăng giá trị.

Sự tự chủ – kết hợp với một kiến trúc doanh nghiệp hỗ trợ sự tự chủ – làm giảm sự phụ thuộc giữa các nhóm. Điều này giúp họ có thể đạt được những thay đổi nhanh chóng hơn. Đây là thành tố chính trong việc giúp các nhóm tạo ra các nguyên mẫu sản phẩm mới và các tính năng để thu thập phản hồi khách hàng, tiến hành kiểm thử A/B và cải thiện dịch vụ khách hàng bằng cách nhanh chóng phản hồi trước các yêu cầu của khách hàng về nâng cấp và xử lý lỗi.

Nếu nhanh chóng biết được người dùng coi trọng cái gì thì chúng ta có thể không mất thời gian xây dựng những thứ không gia tăng giá trị. Thông số quan trọng nhất là: Làm thế nào để chúng ta có thể học hỏi một cách nhanh nhất? Việc thay đổi thời lượng sản xuất là một biến số đại diện⁶ có ích cho thông số này và các nhóm tự chủ đóng vai trò thiết yếu trong cải thiện nó.

6 Biến số đại diện (proxy variable): Là một biến số không liên quan trực tiếp nhưng nó đại diện cho một biến số khác, không quan sát hoặc đo lường được. (BTV)

Hiểu rõ hơn nhu cầu khách hàng

Ở các tổ chức mà công việc vận hành tách biệt thì vòng thông tin phản hồi từ người dùng đến người thiết kế và các kỹ sư làm ra sản phẩm thường chậm và có độ chính xác thấp. Khi mọi người trong nhóm có thể thiết kế các thử nghiệm nhỏ, đưa chúng vào sản xuất và phân tích các thông số, thì cả nhóm tiến hành tiếp xúc với người dùng trên cơ sở thường nhật.

Những người có động lực cao

Khi chúng ta có thể thiết kế một thử nghiệm hoặc đẩy mạnh sửa lỗi hay nâng cấp cho người dùng và xem được kết quả gần như ngay lập tức thì đó là một trải nghiệm tuyệt vời – một bằng chứng về sự tự chủ, khả năng làm chủ và tính mục đích của bạn. Chúng tôi chưa gặp bất kỳ ai từng làm việc theo cách này mà lại muốn quay trở lại kiểu làm việc cũ.

Dễ tính toán lời lãi

Các nhóm liên chức năng làm việc trực tiếp với khách hàng và sở hữu một dịch vụ trọn chu trình thì dễ tính toán lời lãi (P&L) cho dịch vụ hơn. Chi phí cho dịch vụ đơn giản chỉ là chi phí nguồn lực dành cho nhóm cộng với lương của họ. Điều này cho phép chúng ta sử dụng những con số đô-la đơn giản để xác định các nhóm tạo ra lợi nhuận cao nhất cho công ty. Cần lưu ý rằng điều này, nếu được thực hiện theo luật định, thường đòi hỏi mức độ chuyên môn phức tạp hơn để xác định chi phí với độ chính xác không cần thiết.

Đây là một việc cần làm để tiếp nhận các nguyên tắc Yêu cầu Nhiệm vụ trong một doanh nghiệp khởi nghiệp đang phát triển, nhưng lại là điều khác hoàn toàn trong một doanh nghiệp có cách tiếp cận truyền thống và tập trung hơn trong quản lý và ra quyết định. Nguyên tắc Yêu cầu Nhiệm vụ thay đổi một cách quyết liệt tư duy của chúng ta về công tác quản lý, đặc biệt là quản lý rủi ro, chi phí và các kết quả khác ở cấp độ hệ thống. Nhiều tổ chức áp dụng một cách tiếp cận duy nhất để quản lý rủi ro và chi phí với các quy trình tập trung hóa trong quản lý phát hành phần mềm (của bộ phận IT) và phân bổ ngân sách (của bộ phận tài chính). Theo Yêu cầu Nhiệm vụ, các nhóm có thẩm quyền và trách nhiệm quản lý chi phí và rủi ro một cách phù hợp với điều kiện cụ thể của họ. Vai trò của bộ phận tài chính, ban quản lý dự án, các kiến trúc sư doanh nghiệp, các nhóm GRC⁷ và các nhóm tập trung khác thay đổi: Họ cụ thể hóa các điều kiện mục tiêu, giúp tạo dựng tính minh bạch và cung cấp sự hỗ trợ cũng như các công cụ theo yêu cầu, nhưng không chỉ ra cách quản lý chi phí, quy trình và rủi ro.

⁷ Tức nhóm phụ trách việc quản trị (Governance), quản lý rủi ro (Risk management) và sự tuân thủ (Compliance). (BTV)

Chúng ta sẽ thảo luận các cách tiếp cận tinh gọn trong quản lý và tài chính trong Phần IV.

PHÁT TRIỂN KIẾN TRÚC CỦA BẠN BẰNG CÁCH SỬ DỤNG ỨNG DỤNG SỐNG BÁM⁸

⁸ Ứng dụng sống bám (strangler application): Được đặt tên theo một hiện tượng sinh tồn khi một loài cây mọc trong các khu rừng nhiệt đới (có tên gọi là cây thắt cổ) sống trên cành các loại cây khác và ăn dần tới tận gốc cây chủ. (BTV)

Các nhóm tự chủ sẽ không tạo ra nhiều sự khác biệt về kết quả khách hàng nếu kiến trúc doanh nghiệp ngăn cản các nhóm tiến hành các thử nghiệm và nhanh chóng đáp ứng các nhu cầu khách hàng. Để tạo thuận lợi cho cả phân phối liên tục và việc phi tập trung hóa, các nhóm phải có khả năng tạo ra những thay đổi nhanh chóng và an toàn. Không may là thực tế cho thấy có nhiều doanh nghiệp có hàng nghìn hệ thống liên kết chặt chẽ và rất khó tạo ra sự thay đổi với chúng mà không phải làm thay đổi một loạt các hệ thống phụ thuộc khác. Một trong những hệ thống phụ thuộc đó thường là hệ thống lưu trữ được duy trì bởi một nhóm có nhiệm vụ phổ biến các nội dung cập nhật định kỳ vài tháng một đánh đổi bằng việc mất đi một số thông tin quan trọng.

BÍ QUYẾT

Kiến trúc để Phân phối Liên tục và theo định hướng dịch vụ

Kiến trúc để phân phối liên tục và theo định hướng dịch vụ có nghĩa là phát triển các hệ thống có khả năng kiểm thử và khả năng triển khai. Các hệ thống có khả năng kiểm thử là những hệ thống có thể nhanh chóng tạo độ tin tưởng cao về độ chính xác mà không phụ thuộc vào kiểm thử thủ công tăng cường trong các môi trường tích hợp tốn kém. Các hệ thống có khả năng triển khai là các hệ thống được thiết kế để có thể triển khai nhanh, an toàn và độc lập trong môi trường kiểm thử và môi trường vận hành (trong trường hợp các hệ thống dựa trên nền web). Những yêu cầu “liên chức năng” này cũng quan trọng không kém hiệu năng, an toàn, khả năng phát triển và độ tin cậy nhưng lại thường bị bỏ qua hoặc không được ưu tiên.

Phản ứng phổ biến đối với việc bế tắc trong một “quả bóng bùn lớn” là đầu tư vào một dự án khổng lồ nhằm thay thế các hệ thống. Những dự án như thế này thường mất nhiều tháng hoặc nhiều năm trước khi có thể đem lại giá trị cho người dùng và việc chuyển từ hệ thống cũ sang hệ thống mới thường được thực hiện theo kiểu “vụ nổ lớn”. Chúng cũng vấp phải những rủi ro cao về độ trễ, chi tiêu quá ngân sách và phải bị hủy bỏ. Không nên thực hiện một chương trình làm việc cồng kềnh được đầu tư từ ngân sách để tiến hành tái cấu trúc các hệ thống. Đây cần là một hoạt động liên tục được thực hiện như là một phần của quy trình phát triển sản phẩm.

Amazon đã không thay thế cấu trúc Obidos của họ bằng một chương trình thay thế “vụ nổ lớn”. Thay vào đó, họ dần chuyển sang một kiến trúc định hướng dịch vụ, trong khi tiếp tục cung ứng các chức năng mới, sử dụng một kết cấu được gọi là “chiến thuật cây thắt cổ”. Như Martin Fowler mô tả, kết cấu này liên quan đến việc thay thế dần một hệ thống bằng việc đưa các tính năng mới vào một ứng dụng mới có tính gắn kết lỏng lẻo với hệ thống hiện tại, chỉ chuyển đổi tính năng hiện tại từ ứng dụng gốc khi cần thiết. Theo thời gian, ứng dụng cũ bị “siết chết” – giống như một cái cây bị loài cây thắt cổ này ký sinh trên đó và bám chặt đến chết (Hình 10-3).

Hình 10-3. Sự phát triển của tiết lưu

Các ứng dụng sống bám nên sử dụng các phương pháp đã được đề cập trong các phần trước của cuốn sách này. Có một số quy tắc quan trọng cần tuân thủ khi thực hiện kết cấu sống bám:

Bắt đầu bằng việc cung ứng chức năng mới, ít nhất là ở lần đầu tiên

Luôn tìm cách đáp ứng một nhu cầu mà phần mềm hiện thời chưa cung cấp và dành ưu tiên cho các tính năng sử dụng chi phí trì hoãn chia cho thời gian (CD3) như được trình bày ở Chương 7, để bảo đảm bạn cung ứng lượng giá trị lớn nhất trong thời gian ngắn nhất có thể.

Không nỗ lực chuyển đổi chức năng hiện tại trừ khi việc đó hỗ trợ cho sự thay đổi quy trình kinh doanh

Sai lầm lớn nhất mà mọi người mắc phải là chuyển đổi tính năng hiện tại theo kiểu để cho có. Điều này thường tạo thêm tính phức tạp cho các quy trình kinh doanh không khác gì nhiều năm trước đó, và đó là sự lãng phí to lớn. Bất kỳ khi nào bạn được đề nghị bổ sung một tính năng thể hiện sự thay đổi đối với một quy trình kinh doanh, hãy đến và quan sát quy trình ngay từ đầu và tìm các phương pháp đơn giản hóa quy trình đó trước khi viết mã để hỗ trợ tính năng đó. Bạn sẽ thấy rằng nhiều sự phức tạp ngẫu nhiên trong quy trình kinh doanh thường xảy đến từ việc bị buộc phải sử dụng các phần mềm cũ mà bạn đang thay thế!

Nhanh chóng tạo ra kết quả nào đó

Hãy đảm bảo rằng việc đưa ra lần đầu ứng dụng mới của bạn phải đủ nhỏ để bạn có thể thúc đẩy triển khai nó và cung cấp giá trị trong một vài tuần đến một vài tháng. Khi tạo ra mô- đun đầu tiên, một việc rất khó, nhưng cần thiết, là phải chống lại để chống hiện tượng “bùng nổ tính năng⁹” (feature creep). Thước đo thành công cho lần phát hành đầu tiên là việc bạn thực hiện nhanh như thế nào chứ không phải có bao nhiêu tính năng trong ứng dụng đó. Điều này thường đạt được bằng cách sử dụng cách tiếp cận “lát cắt đứng”, theo đó chúng ta thiết kế bổ sung cục bộ các tính năng từ đầu đến cuối trong toàn bộ nền tảng công nghệ.

⁹ Bùng nổ tính năng (feature creep): Là hành động ồ ạt bổ sung tính năng mới trong một sản phẩm. (BTV)

Thiết kế để tạo khả năng kiểm thử và khả năng triển khai

Tính năng trong ứng dụng mới phải luôn được xây dựng bằng cách sử dụng các kỹ thuật phát triển phần mềm tốt: phát triển theo định hướng kiểm thử, tích hợp liên tục và một thiết kế mô-đun kín, gọn và kết nối lỏng lẻo. Các ứng dụng sống bám là cơ hội để kiểm thử những kỹ thuật này, vì thế hãy bảo đảm rằng nhóm đang nhiệt tình thực thi các phương pháp này và có đủ kinh nghiệm để có cơ hội thành công.

Kiến tạo phần mềm mới chạy trên PaaS (dịch vụ hạ tầng)

Hãy làm việc với nhóm vận hành để đưa ra được bản thiết kế phần mềm tương ứng với nền tảng dịch vụ (chúng ta sẽ bàn cụ thể ở Chương 14). Nếu nhóm vận hành chưa sẵn sàng làm việc này, hãy làm việc với họ để bảo đảm rằng hệ thống không làm gia tăng sự phức tạp cho môi trường hoạt động hiện tại.

Dĩ nhiên là phải có sự trả giá cho việc chuyển đổi dần. Nhìn chung, sự chuyển đổi dần mất nhiều thời gian hơn so với việc tái cấu trúc “vụ nổ lớn” để phân phối cùng một loại tính năng. Tuy nhiên, vì một ứng dụng sống bám cung ứng cho khách hàng giá trị ngay từ đầu, phát triển để đáp ứng nhu cầu thay đổi của khách hàng và có thể tiến triển với tốc độ của chính nó nên thường được ưa chuộng hơn.

Kiến trúc doanh nghiệp thường được định hướng bởi các kế hoạch đắt đỏ và đưa từ trên xuống để “hợp lý hóa” kiến trúc, chuyển từ các hệ thống kế thừa sang một nền tảng hiện đại và loại bỏ sự trùng lắp để tạo ra một nguồn chân lý duy nhất (single source of truth-SSOT¹⁰). Thông thường, trạng thái kết thúc được thể hiện bằng một biểu đồ đẹp đẽ và vừa vặn trong khổ một tờ giấy lớn. Tuy nhiên, trạng thái này hiếm khi đạt được vì hệ sinh thái mà kiến trúc này phục vụ luôn luôn thay đổi quá nhanh, và những lợi ích hứa hẹn còn hiếm khi đạt được hơn nữa. Thông thường, sẽ diễn ra thực tế là các kiến trúc mới được bổ sung, nhưng các hệ thống được xác định là sẽ bị thay thế lại không bao giờ thực sự ngừng hoạt động, làm gia tăng tính phức tạp và khiến việc thay đổi mọi việc trong tương lai càng khó khăn hơn.

¹⁰ Nguồn chân lý duy nhất (single source of truth-SSOT): Chỉ phương pháp tổ chức các mô hình thông tin sao cho mỗi yếu tố thông tin đều được lưu trữ đúng một lần. (BTV)

BÍ QUYẾT

Tạo gắn kết kiến trúc bằng việc chỉ rõ các điều kiện mục tiêu, chứ không phải các sáng kiến kiến trúc hay tiêu chuẩn hóa.

Kinh nghiệm cho thấy việc tiêu chuẩn hóa một chuỗi công cụ hay nền tảng công nghệ cụ thể vừa không cần thiết vừa không đủ để đạt được các mục đích kiến trúc doanh nghiệp như giúp cho các nhóm phản ứng nhanh chóng trước các yêu cầu thay đổi các yêu cầu, tạo ra các hệ thống hiệu năng cao ở quy mô phù hợp hoặc giảm nguy cơ bị xâm nhập hoặc đánh cắp dữ liệu. Giống như việc chúng ta thúc đẩy đổi mới sản phẩm và quy trình thông qua Kata Cải tiến, chúng ta có thể thúc đẩy sự gắn kết cấu trúc theo cách tương tự. Các mục đích kiến trúc, ví dụ như hiệu năng, tính khả dụng và độ an toàn mong muốn, cần được tiếp cận bằng cách không ngừng chỉ rõ các điều kiện mục tiêu ở cấp chương trình. Theo Yêu cầu Nhiệm vụ, hãy đưa ra tầm nhìn rõ ràng về các mục đích kiến trúc doanh nghiệp của bạn mà không cần chỉ rõ phương pháp để đạt được các mục đích đó, và tạo điều kiện để các nhóm có thể quyết định cách thức đạt được mục đích thông qua việc thử nghiệm và hợp tác. Chúng ta sẽ bàn chi tiết hơn về các giải pháp thay thế cho việc tiêu chuẩn hóa và các vấn đề liên quan trong Chương 14.

Chúng ta làm tốt hơn nhiều khi chấp nhận rằng ta sẽ luôn ở trạng thái thay đổi, và từ từ và từng bước gia tăng cường độ làm việc để giảm độ phức tạp thông qua kết cấu ứng dụng sống bám. Hãy tìm cách tính toán phạm vi của các hệ thống mà bạn muốn loại bỏ và tìm cách làm cho nó hữu hình để các nhóm có thể làm việc để giảm quy mô và cuối cùng là loại bỏ các hệ thống này trong khi chúng vẫn tiếp tục đem lại giá trị cho khách hàng. Hãy chấp nhận rằng việc phát triển kiến trúc doanh nghiệp và giảm độ phức tạp không cần thiết là một quá trình liên tục, không có điểm kết.

KẾT LUẬN

Việc tiến nhanh ở quy mô phù hợp yêu cầu phải thực hiện Yêu cầu Nhiệm vụ. Một phương pháp được sử dụng phổ biến là thành lập các nhóm nhỏ có tính gắn kết chặt chẽ nhưng ít phụ thuộc vào nhau. Tuy nhiên, căn cứ vào sự phụ thuộc mạnh mẽ giữa kiến trúc hệ thống và các dòng giao tiếp do Melvin Conway quan sát và đưa vào thành luật mang tên ông, thì chúng ta cũng cần phát triển một kiến trúc hệ thống hỗ trợ kiểu tổ chức phân quyền này.

Chuyển từ một mô hình tập trung truyền thống hơn sang loại cấu trúc được mô tả trong chương này là một việc khó. Chúng ta phải tiến hành từ từ và từng bước tăng cường. Nó đòi hỏi các quy trình tập trung hiện tại – cụ thể là việc phân bổ ngân sách, mua sắm, quản lý rủi ro, quản lý và quản lý phát hành – phải thay đổi. Những vấn đề này được bàn thảo trong phần cuối của cuốn sách này, Phần IV.

Mặc dù những thay đổi này là khó khăn và mất thời gian nhưng chúng ta không nên trì hoãn. Điểm then chốt là phải tìm ra phương pháp thực hiện những thay đổi nhỏ và tăng dần khả năng đem lại sự cải tiến của kết quả khách hàng, và sau đó thì tiếp tục tiến bước. Giống như chúng ta áp dụng kết cấu sống bám vào kiến trúc doanh nghiệp, chúng ta cũng có thể áp dụng nó vào các quy trình và văn hóa tổ chức; đây là chủ đề của chương cuối, Chương 15.

Câu hỏi dành cho độc giả

◆ Các nhóm của bạn có thể tiến hành các thử nghiệm và đạt được các kết quả khách hàng một cách độc lập không hay là phải dựa vào các nhóm khác để hoàn thành mọi công việc?

◆ Bạn có thể triển khai từng phần của hệ thống một cách độc lập với nhau hay phải đồng loạt ra mắt mọi thứ vào một thời điểm?

◆ Khối lượng công việc nhỏ nhất mà bạn có thể làm để tạo thuận

lợi cho việc thử nghiệm hoặc triển khai độc lập một nhóm

hoặc bộ phận/dịch vụ đơn lẻ là bao nhiêu?

◆ Các thành viên trong nhóm của bạn được khen thưởng như thế nào? Điều này khuyến khích hay làm nhụt chí họ trong việc phối hợp với những người khác trong nhóm hoặc với các nhóm khác?

Phần IVCHUYỂN ĐỔI

Ai cũng đều nghĩ đến việc thay đổi thế giới nhưng chẳng ai nghĩ đến việc thay đổi bản thân.

− LEO TOLSTROY

Nếu bạn chú ý từ đầu cuốn sách đến đây thì bạn đã hiểu biết khá rõ về cách áp dụng những khái niệm và nguyên tắc tinh gọn này để làm ra các sản phẩm phần mềm tuyệt vời và về tầm quan trọng của chiến lược và văn hóa trong việc tạo thuận lợi cho tiến trình khám phá và khai thác các cơ hội kinh doanh mới. Tuy nhiên, để có được phần thưởng cao nhất cho các nỗ lực của mình, các nguyên tắc và khái niệm tinh gọn này cần được phổ quát trong toàn tổ chức. Chỉ như vậy chúng ta mới nhận thấy được giá trị đầy đủ của công việc chúng ta bỏ công sức ra làm, khám phá những ý tưởng mới và khai thác những ý tưởng đem lại giá trị cho khách hàng.

Chúng ta hiểu rõ rằng những khái niệm này rất hiệu quả trong đáp ứng nhu cầu của một môi trường biến động mau lẹ và cạnh tranh khốc liệt. Tuy nhiên, rất khó để phát triển các khái niệm tinh gọn thành cải tiến quy trình, các giải pháp phần mềm thương mại có sẵn (COTS) và sự phát triển và hỗ trợ các hệ thống nội bộ, đặc biệt các hệ thống lưu trữ. Mối quan hệ của chúng ta với các nhà cung cấp và bán hàng cũng tạo ra một rào cản khác nữa. Bản chất mối quan hệ của chúng ta với các nhà cung cấp các giải pháp riêng lẻ, chuyên biệt hoặc theo nhu cầu khách hàng thường cản trở việc phối hợp, khả năng phản hồi nhanh hoặc những thay đổi nhỏ từng bước. Chúng ta cần tìm kiếm các nhà cung cấp vui lòng đối xử với chúng ta như chính chúng ta mong muốn đối xử với khách hàng của mình. Chúng ta phải khuyến khích các nhà cung cấp lắng nghe chúng ta, hiểu những gì chúng ta cần và tiến hành thử nghiệm. Họ phải sẵn lòng đồng hành với chúng ta trong tiến trình cải tiến.

Làm gia tăng tính phức tạp cho vấn đề này, nhiều cách tiếp cận truyền thống của chúng ta đối với GRC, quản lý tài chính, mua sắm, quản lý bên bán hàng/nhà cung cấp và các nguồn nhân lực (tuyển chọn, đề bạt, thù lao) góp phần tạo thêm lãng phí và những điểm bế tắc. Những điều này chỉ có thể được loại bỏ khi toàn bộ tổ chức đều nắm được các khái niệm tinh gọn và mọi người cùng làm việc theo một chí hướng.

Xây dựng một tổ chức tinh gọn không phải là màn phô trương của một cá nhân hoặc một bộ phận. Nó không hiệu quả nếu sử dụng một lực lượng tác nghiệp chiến thuật đặc biệt. Chúng ta không thể ra lệnh rằng từ nay trở đi, mọi người phải làm việc theo cách này và trông đợi họ điều chỉnh theo kế hoạch hoạt động của chúng ta. Chuyển đổi tinh gọn đích thực là kết quả của các nhà lãnh đạo dám theo đuổi cam kết, không sợ hãi, những người khuyến khích và tạo thuận lợi cho những tư duy tinh gọn phổ quát ra toàn bộ tổ chức, chứ không chỉ là các sản phẩm trực diện khách hàng. Những người đứng đầu cần đi thực tế, trò chuyện và làm gương cho mọi người. Họ cần gạt bỏ bản ngã cá nhân, lắng nghe và tôn trọng các quan điểm trái chiều đồng thời xây dựng các mối quan hệ đáng tin cậy ở tất cả các cấp của tổ chức. Điều thiết yếu là các lãnh đạo mới phải khuyến khích để các khái niệm và tập quán tinh gọn hòa quyện vào văn hóa của tổ chức.

Mọi người phải cảm thấy mình được trao quyền đưa ra các quyết định có rủi ro và kiểm thử các ý tưởng mới trong khi nhận thức rõ về trách nhiệm của mình với khách hàng và duy trì tính gắn kết với chiến lược chung của tổ chức. Là lãnh đạo, chúng ta cần đặt ra các giới hạn và điều kiện cho mọi người nhưng phải bảo đảm rằng chúng không quá khắt khe. Khi mọi người thống nhất theo đuổi một mục tiêu chung, và chúng ta có sự đồng cảm với khách hàng và phục vụ trước tiên cho nhu cầu của khách hàng thì nhiều người sẽ nhận ra được những rủi ro nào là có thể chấp nhận và những rủi ro nào thì không.

Xung đột nảy sinh khi các giá trị chuẩn mực của chúng ta không phù hợp với thực tiễn. Đây là khi mà việc mô hình hóa thái độ mà chúng ta hy vọng thấy ở mọi người là việc quan trọng nhất. Không có công thức nào, chỉ dẫn nào hoặc nghi thức nào là đúng đối với mọi người. Mỗi chúng ta cần phải dành ra một khoảng thời gian mỗi ngày, thậm chí là vài lần mỗi ngày để xem xét hành động của riêng mình và quyết định liệu nó có tương đồng với các giá trị đã được tán thành và giúp chúng ta đi đúng hướng hay không.

Tư duy tinh gọn không thể phát triển ở một tổ chức có phong cách quản lý tập trung, chỉ huy và kiểm soát. Tuy nhiên, chúng ta vẫn cần duy trì tính rõ ràng và minh bạch với những gì mọi người đang thực hiện. Các tổ chức lớn không dễ nhận thấy sự cân bằng này và chúng ta phải thấy rằng việc liên tục điều chỉnh là cần thiết. Nhiều người trong tổ chức của chúng ta sẽ coi sự dịch chuyển văn hóa này là một mối đe dọa và tìm cách ngăn cản. Chỉ huy và kiểm soát là việc dễ dàng; tôi tuân theo các quy tắc và nếu nó không hiệu quả thì đó không phải là lỗi của tôi. Tuy nhiên, nếu bạn yêu cầu tôi ra quyết định và chịu trách nhiệm cho các quyết định đó thì hẳn ai đó sẽ giữ tôi lại và yêu cầu tôi phải cân nhắc về những sai sót mà chắc chắn tôi sẽ phạm phải. Hãy trao cho tôi quyền chỉ huy và kiểm soát!

Nếu thành công trong việc tạo ra một tổ chức tinh gọn, chúng ta sẽ có những thất bại và sự thụt lùi ở tất cả các cấp và do tất cả mọi người gây ra. Nếu không thành công, có nghĩa chúng ta đã không xây dựng được một văn hóa hiệu năng cao, có độ tin cậy cao, và đang tiếp tục đánh giá hiệu năng của mình bằng các thông số giả, chứ không phải kết quả thật. Chúng ta sẽ không bao giờ có được văn hóa của một tổ chức học hỏi nếu chúng ta không được phép phạm sai lầm và làm gì đó tệ hại trước khi trở nên tốt hơn.

Trong phần này, chúng tôi tập trung thảo luận về cách theo đuổi việc chuyển đổi tổ chức, một công việc không có điểm dừng. Chúng tôi sẽ giải quyết một số nội dung chung nhất mà chúng tôi thấy có sự không ăn khớp giữa các khái niệm tinh gọn, với các nguyên tắc, tập quán và quy trình quản lý, lãnh đạo đang phổ biến hiện nay. Những khoảng cách này xuất hiện khi chúng ta đối mặt với những trở ngại trong việc cung cấp giá trị tốt hơn cho khách hàng hoặc khi chúng ta không hài lòng hay không hoàn thành công việc thường nhật của mình. Chúng tôi hy vọng các độc giả sẽ cảm thấy hứng thú và nỗ lực tìm ra phương pháp vượt qua những trở ngại này và chia sẻ thành công – và những thất bại – của mình với những người khác.

Chương 11Phát triển nền văn hóa đổi mới

Khả năng cạnh tranh và sống sót của công ty bạn không chỉ nằm ở giải pháp mà còn ở khả năng của các nhân viên trong công ty bạn trong nắm bắt tình huống và đưa ra giải pháp.

− MIKE ROTHER

Lúc này chúng ta đều thừa nhận thực tế rằng học hỏi là việc suốt đời theo đuổi tiến trình thay đổi. Và nhiệm vụ cấp thiết nhất là phải dạy mọi người cách học hỏi.

− PETER DRUCKER

Các bạn biết đó, tôi dành tất cả cho sự tiến bộ. Sự thay đổi chính là điều tôi luôn hướng đến.

− MARK TWAIN

Văn hóa là yếu tố quan trọng nhất trong khả năng thích nghi với môi trường không ngừng thay đổi của một tổ chức. Tuy nhiên, do vô hình, nên việc phân tích văn hóa rất khó và việc thay đổi nó thậm chí còn khó hơn. Mọi tổ chức đều có nền văn hóa độc đáo riêng và có bao nhiêu “nền văn hóa thành công thì có bấy nhiêu tổ chức thành công”. Trong Chương 1, chúng tôi đã trình bày những đặc điểm của một nền văn hóa sáng tạo và hiệu năng cao. Trong chương này, chúng tôi sẽ bàn về cách hiểu văn hóa của tổ chức mà bạn làm việc và những gì mà bạn có thể làm để thay đổi nó.

Văn hóa không ngừng thay đổi ở mỗi tổ chức. Các nhân viên và lãnh đạo mới gia nhập, có người thì rời bỏ, các chiến lược và sản phẩm hình thành và biến mất, còn thị trường thì liên tục thăng trầm. Câu hỏi quan trọng nhất là: Chúng ta có thể chủ động phát triển văn hóa tổ chức của mình để đáp ứng những thay đổi này trong môi trường hay không?

Để hiểu được cách nâng cao văn hóa tổ chức, chúng ta cần hiểu được nền tảng của nó. Chúng tôi giới thiệu một mô hình văn hóa tổ chức và bàn cách đánh giá mô hình đó. Chúng tôi hành động theo các chiến lược để kích hoạt những thay đổi về tổ chức với mục đích làm cho những chiến lược này tự đứng vững. Cuối cùng, chúng tôi đánh giá mối quan hệ giữa các cá nhân và tổ chức và bàn cách tuyển dụng và giữ chân những người “tốt”.

MÔ HÌNH HÓA VÀ ĐÁNH GIÁ VĂN HÓA CỦA BẠN

Các CEO có thể nói chuyện và ba hoa cả ngày về văn hóa nhưng các nhân viên biết rõ ai là những tên ngốc.

− JACK WELCH

Trong cuốn Corporate Culture Survival Guide (tạm dịch: Cẩm nang về sự sống còn của Văn hóa Tổ chức), Schein định nghĩa văn hóa là một “kết cấu của những giả định ngầm do một nhóm nghiên cứu ra trong quá trình giải quyết các vấn đề của nhóm khi phải thích nghi với bên ngoài và thống nhất nội bộ; kết cấu đó đủ hiệu quả để được coi là có giá trị và vì vậy được truyền lại cho những thành viên mới, coi đó là một cách làm đúng đắn để lĩnh hội, tư duy và cảm nhận về những gì liên quan đến các vấn đề này”. Chữ “ngầm” trong khái niệm này có ý nghĩa quan trọng, làm cho văn hóa trở nên vô hình. Shanley Kane, tác giả của cuốn Your Startup Is Broken: Inside the Toxic Heart of Tech Culture (tạm dịch: Doanh nghiệp khởi nghiệp của bạn đổ vỡ: Bên trong trái tim nhiễm độc của nền văn hóa công nghệ), đưa ra một cách nhìn khác, cho rằng “văn hóa đích thực của chúng ta chủ yếu được tạo nên bởi những thứ mà không ai nói ra… Nói đến văn hóa là nói về động lực sức mạnh, những ưu tiên và niềm tin ngầm, các yếu tố thần thoại, các xung đột, sự thực thi những chuẩn mực xã hội, việc hình thành các nhóm cùng/khác lợi ích và việc phân phối tài sản và kiểm soát nội bộ các công ty”.

Mặc dù vô hình nhưng văn hóa vẫn có thể đánh giá được và có một phần lớn công việc được dành cho việc này. Tất nhiên, mọi phương pháp đều dựa trên một mô hình cơ bản và tất cả các mô hình đều bị giới hạn ở một phạm vi nào đó. Tuy nhiên, những phương pháp đánh giá này, rất quan trọng vì chúng làm cho văn hóa trở nên hữu hình và thu hút sự quan tâm của mọi người. Đây là một số ví dụ về những việc đã được thực hiện để đánh giá văn hóa:

◆ Karen E. Watkins và Victoria J. Marsick phát triển Dimensions of the Learning Organization Questionnaire – DLOQ (Khuôn khổ bộ câu hỏi cho tổ chức học hỏi), đã được nghiên cứu rộng rãi trong các tài liệu học thuật. Bạn có thể lấy bộ câu hỏi miễn phí này tại Web.taisachnhanh.cloud/instructions.html

◆ Bộ Khảo sát 12 câu hỏi của Gallup (Gallup’s Q12 survey) đặt ra những câu hỏi mà họ tin là “12 câu hỏi duy nhất khả dĩ” để đánh giá sự tham gia của nhân viên. Bạn có thể tìm thấy những câu hỏi này, cùng với nhiều thông tin khác tại http:// q12.Web.taisachnhanh.cloud/.

◆ Trong Chương 1, chúng tôi đã bàn về cách mà bản báo cáo Tình hình Phát triển và Vận hành năm 2014 đánh giá hai vấn đề: mức độ hài lòng với công việc và văn hóa (sử dụng mô hình Westrum) và tác động của chúng với hiệu năng của tổ chức. Các phân tích chỉ ra rằng mô hình của Westrum dự đoán được cả sự hài lòng với công việc và hiệu năng của tổ chức trong môi trường làm việc trí óc. Hãy đọc thêm tại http://bit. ly/1v71SJL.

BÍ QUYẾT

Những thao tác tiến hành các khảo sát về văn hóa

Sự cần thiết của Khảo sát Văn hóa

Dù bạn sử dụng dịch vụ hay tự tiến hành khảo sát thì hãy thận trọng với việc thu thập thông tin. Để có được những câu trả lời trung thực, đừng yêu cầu mọi người tiết lộ thông tin nhận dạng. Chỉ trình bày kết quả tổng hợp. Thu thập một số thông tin nhân khẩu học có thể giúp bạn biết được nhiều vấn đề, ví dụ như sự khác biệt về giới tính hoặc vị trí công tác, nhưng chỉ khi bạn có con số khảo sát đủ lớn thì mới bảo đảm được tính bí mật. Hãy chú ý đến cách mà thông tin có thể làm hại những người tham gia khảo sát. Ở một doanh nghiệp lớn, các nhà quản lý đã phản ứng trước kết quả khảo sát nghèo nàn trong bộ phận của họ bằng cách ra lệnh cho những người báo cáo phải làm cho các báo cáo sáng sủa hơn trong lần tiếp theo.

Hãy tách rời các cuộc khảo sát văn hóa với việc xem xét lương thưởng và hiệu năng. Hãy bảo đảm mọi nhân viên đều nhận được kết quả tổng hợp và các giám đốc điều hành sẽ tổ chức các cuộc họp để thảo luận về kết quả khảo sát và lập kế hoạch cho các bước tiếp theo. Tiến hành các cuộc khảo sát định kỳ hằng năm hoặc 6 tháng một lần để làm cơ sở so sánh và đánh giá sự thay đổi theo thời gian.

Đánh giá văn hóa tổ chức và làm cho các vấn đề trở nên hữu hình là bước đầu tiên. Tiếp theo, chúng ta phải điều tra tại sao nền văn hóa đó lại hình thành. Để trả lời được thắc mắc này, sẽ có ích khi sử dụng mô hình của Schein, mô hình chia văn hóa thành ba lớp: Các thực thể hữu hình (Artifacts), Các giá trị theo đuổi (Espoused Values) và Các giả định ngầm hiểu chung (Shared Tacit Assumptions) (Hình 11-1).

Sự thiếu nhất quán giữa các giá trị theo đuổi và các thái độ ứng xử quan sát được trong một tổ chức là phổ biến. Những thái độ ứng xử đó là những dấu hiệu rõ nét hơn về các giá trị thực. Ai được khen thưởng cho những hành vi nào? Ai được tuyển dụng, được đề bạt hoặc bị sa thải? Để hiểu được bản chất và nguồn gốc của các giá trị thực, chúng ta phải đi tiếp xuống lớp giả định ngầm hiểu chung. Lớp này rất khó bóc tách nhưng lại là quan trọng nhất cần phải hiểu được.

Hình 11-1. Các lớp của văn hóa tổ chức

Schein trình bày một hệ thống toàn diện các giả định ngầm, ở đó yếu tố quan trọng nhất là những niềm tin mà lãnh đạo và nhà quản lý dành cho nhân viên. Trong cuốn The Human Side of Enterprise (tạm dịch: Khía cạnh nhân lực của doanh nghiệp), Douglas McGregor mô tả hai nhóm niềm tin tương phản nhau tồn tại ở các nhà quản lý mà ông quan sát được và gọi là Thuyết X và Thuyết Y. Các nhà quản trị theo Thuyết X tin rằng mọi người vốn dĩ lười nhác, không tham vọng và coi trọng vấn đề an toàn hơn trách nhiệm; các kỹ thuật khuyến khích từ bên ngoài (cây gậy và củ cà rốt) là phương pháp hiệu quả nhất đối với người lao động. Trái lại, các nhà quản trị theo Thuyết Y tin rằng “nhân viên có thể và sẽ kết nối mục đích riêng của họ với mục đích của tổ chức, vì vậy họ giao phó công việc nhiều hơn, đóng vai trò như các giáo viên và huấn luyện viên để giúp nhân viên gia tăng nhiệt huyết và kiểm soát những gì thuộc trách nhiệm giám sát của họ”.

Như chúng ta đã thấy ở Chương 1, mặc dù những hình thức động viên bên ngoài, ví dụ như tiền thưởng, thường hiệu quả trong thế giới lao động chân tay và kiểu Taylor¹ nhưng lại giảm hiệu năng trong môi trường làm việc trí óc. Những người làm những công việc không theo thường lệ được khích lệ bởi các yếu tố bên trong. Dan Pink tóm lược các yếu tố đó là “1. Tự chủ − khát vọng được định hướng cuộc sống riêng của mình. 2. Làm chủ − sự hối thúc để ngày càng làm tốt hơn một việc gì đó. 3. Mục đích − mong muốn làm những gì mà chúng ta làm để phục vụ cái gì đó lớn hơn chính chúng ta.”

¹ Taylorism, còn được gọi là Chủ nghĩa Taylor là lý thuyết quản lý dựa trên quá trình phân tích, tổng hợp các quy trình công việc nhằm nâng cao năng suất lao động (hợp lý hóa lao động); những ý tưởng cốt lõi của lý thuyết được phát triển trong thập niên 1890 bởi Frederick Winslow Taylor, ông tin rằng các quyết định dựa trên kinh nghiệm truyền thống và quy tắc theo kinh nghiệm (rule of thumb) nên được thay thế bằng cách khai thác chuỗi thao tác chính xác sau khi nghiên cứu cẩn thận các cá nhân trong quá trình làm việc. (ND)

Điều đặc biệt khó giải quyết là, bằng cách tạo ra những phản ứng về thái độ theo đúng với với phong cách quản lý của mình, cả hai nhóm quản lý đều tin rằng phong cách quản lý của họ là hiệu quả nhất. Những người nhất quán theo chiến lược quản lý của Thuyết X thì cuối cùng sẽ có trong tay một đội ngũ nhân viên thụ động, ngại thay đổi, không sẵn sàng nhận trách nhiệm và đưa ra “các yêu cầu phi lý về lợi ích kinh tế”. Đây là phản ứng hợp lý của những nhân viên không thỏa mãn được nhu cầu của mình trong doanh nghiệp. Công việc trở thành cái gì đó mang tính cam chịu, họ làm việc chỉ để nhận tiền lương.

Trong một tổ chức mà những người lãnh đạo nghiêng theo Thuyết Y thì công việc của họ là “tạo ra điều kiện để các thành viên trong tổ chức có thể đạt được mục tiêu của mình bằng việc hướng mọi nỗ lực vào sự thành công của doanh nghiệp”, đem giá trị đến cho khách hàng và tổ chức trong khi vẫn phát triển các khả năng riêng của họ. Chừng nào các nhà lãnh đạo và quản lý theo Thuyết X còn chưa chấp nhận quan điểm của Thuyết Y và thể hiện điều đó một cách nhất quán trong tất cả các hành động của mình thì họ sẽ không thể tạo ra được sự khác biệt có thể cảm nhận được trong thái độ ứng xử của mọi người.

Câu chuyện về NUMMI trong Chương 1 là minh chứng sống động của việc thay đổi quan điểm và thái độ ứng xử.

Khó có thể thay đổi văn hóa bằng phác thảo. Theo Schein, “văn hóa rất ổn định và khó thay đổi bởi nó đại diện cho việc học hỏi và tích lũy của một nhóm người – cách tư duy, cảm xúc và nhận thức về thế giới đã làm cho nhóm thành công”.

THAY ĐỔI VĂN HÓA CỦA BẠN

Trong tác phẩm mang tính cách mạng Pedagogy of the Oppressed (tạm dịch: Giáo dục dành cho người bị áp bức), xuất bản năm 1970, Paulo Freire mô tả những gì vẫn đang là mô hình giáo dục chủ đạo ngày nay. Trong mô hình này, các sinh viên được xem là “tài khoản ngân hàng” rỗng cần được giáo viên lấp đầy bằng tri thức, chứ không phải là những bên tham gia có tiếng nói về việc học cái gì và như thế nào. Mô hình này không được thiết kế để khuyến khích sinh viên học tập, đặc biệt không phải học cách tự suy nghĩ cho chính họ, mà là kiểm soát quá trình học tập, tiếp cận thông tin và khả năng phân tích phản biện của sinh viên. Bằng cách này, hệ thống giáo dục sẽ kéo dài sự tồn tại của các cấu trúc xã hội và hệ thống phân quyền đương đại.

Tương tự như vậy, hầu hết các công ty đều có xu hướng đối xử với nhân viên của mình giống như các tài khoản ngân hàng đã được lấp đầy để vắt lọc lấy những kỹ năng và tri thức phục vụ cho các mục tiêu của công ty. Ngụ ý này thể hiện khi chúng ta đề cập đến các nhân viên như là “những nguồn lực” và tìm cách gia tăng cường độ sử dụng và năng suấtmà không mấy quan tâm đến sự phát triển cá nhân của họ. Thái độ ứng xử kiểu này cho thấy đây là môi trường mà các nhân viên tồn tại chủ yếu với tư cách những nguồn cung cấp lao động chứ không phải những người chủ động tham gia tạo ra giá trị. Trái lại, các tổ chức có hiệu năng cao thường hoạt động hiệu quả cả trong phát triển và khai thác các khả năng độc đáo của các nhân viên.

Các tổ chức có quan điểm “tài khoản ngân hàng” đối với nhân viên có xu hướng xem xét sự thay đổi dưới con mắt kinh doanh. Cách tiếp cận quá phổ thông và nhiều khuyết điểm này thể hiện ở việc cấp ngân sách cho một chương trình thay đổi và kỳ vọng có thể “chỉnh đốn” tổ chức cho phù hợp với mục đích đề ra. Thay đổi tổ chức được coi như một sản phẩm, trong đó các nhà tư vấn là người bán, lãnh đạo là người chi và phần còn lại của tổ chức là bên tiêu thụ theo hướng dẫn.

Những chương trình thay đổi này thường tập trung vào tái tổ chức các nhóm, điều chỉnh các cấu trúc, cử nhân viên tham gia các khóa huấn luyện ngắn hạn và đưa vào áp dụng các công cụ và phương pháp luận trong toàn tổ chức. Những chiến lược này thường không đem lại kết quả vì không tác động đến sự thay đổi hình thái hành vi của mọi người. Mike Rother đã chỉ ra trong cuốn Toyota Kata, “yếu tố quyết định không phải là ở hình thức của tổ chức mà là cách con người hành động và phản ứng”. Điều này chủ yếu được quyết định bởi ban lãnh đạo và quản lý. Có thể đưa ra một vài ví dụ: mọi người có được trao quyền tự chủ trong hành động và được tin tưởng là sẽ dám chấp nhận rủi ro? Những thất bại sẽ bị trừng phạt hay sẽ dẫn đến việc tìm hiểu nguyên nhân và cải thiện hệ thống của chúng ta? Việc liên lạc liên chức năng được khuyến khích hay bị hạn chế?

Chúng ta đã bắt đầu cuốn sách này bằng việc bàn về trường hợp NUMMI, một tổ chức phá sản đã được cải tổ theo mô hình lãnh đạo và quản lý mới. Mặc dù vẫn cùng đội ngũ nhân viên đó nhưng NUMMI đã đạt mức chất lượng và sản lượng cao phi thường, đồng thời chi phí lại giảm xuống. Trong bài báo trên tạp chí MIT Sloan Management Review, John Shook, nhân viên người Mỹ đầu tiên của Toyota City, đã nói về cách mà tổ chức của ông thay đổi văn hóa như thế này:

Kinh nghiệm tại NUMMI đã dạy tôi rằng để thay đổi văn hóa, trước tiên không phải thay đổi cách suy nghĩ mà phải thay đổi cách ứng xử của mọi người – tức là những gì họ làm. Những ai muốn thay đổi văn hóa tổ chức của mình cần xác định những việc chúng ta muốn làm, cung cách chúng ta muốn ứng xử và muốn những người khác ứng xử, sau đó huấn luyện và làm những gì được cho là cần thiết để củng cố thái độ ứng xử này. Kết quả là văn hóa sẽ thay đổi... Điều làm nên sự thay đổi văn hóa tại NUMMI không phải là ý niệm trừu tượng về “sự tham gia của nhân viên” hay “một tổ chức học hỏi” hay thậm chí là “văn hóa”. Điều làm nên sự thay đổi văn hóa chính là việc trao cho nhân viên các phương tiện để sử dụng và hoàn thành công việc của mình. Họ chỉ cho nhân viên thấy rõ công việc của mình là gì, tiến hành huấn luyện và cung cấp các công cụ để giúp họ làm việc thành công.

Shook đưa ra cách diễn giải của riêng ông về mô hình Schein, chỉ ra phương pháp mọi người tiếp cận thay đổi văn hóa bằng cách so sánh phương pháp được thực hiện ở MUMMI, thể hiện trong Hình 11-2.

Hình 11-2. Các phương pháp cũ và mới tạo ra sự thay đổi văn hóa (Tạp chí MIT Sloan Management Review năm 2010/ Học viện Công nghệ Massachusetts, đã được đăng ký bản quyền, do Cơ quan Tribune Content Agency cung cấp)

NUMMI có một lợi thế trong thực hiện thay đổi văn hóa. Toàn bộ nhân công đều được tuyển mới, trong đó nhiều công nhân vừa bị sa thải ở nhà máy lắp ráp Fremont. Thật khó để có được sự thay đổi một cách bền vững và có hệ thống mà không để xảy ra bất kỳ một cuộc khủng hoảng nào. Trong cuốn The Corporate Culture Survival Guide, Schein tự hỏi rằng liệu khủng hoảng có phải là điều kiện cần thiết để chuyển đổi thành công và câu trả lời của ông là, “Con người thường muốn tránh sự khó lường và sự bất trắc nên đã hình thành các nền văn hóa. Vì vậy, có một lập luận cơ bản và thiết thực mà người lớn phải biết, đó là chúng ta cần một số nhân tố kích thích mới để phá vỡ trạng thái cân bằng hiện tại. Cách tốt nhất là hãy nghĩ rằng yếu tố kích thích này là sự không khẳng định: có điều gì đó mà chúng ta cảm nhận rằng chúng ta không mong đợi và gây xáo trộn niềm tin hoặc giả định của ta...; sự không khẳng định tạo ra sự lo ngại về khả năng tồn tại² – có điều tồi tệ sẽ xảy ra nếu chúng ta không thay đổi hoặc cảm giác có tội (guilt) – chúng ta nhận ra rằng chúng ta sẽ không đạt được ý tưởng hay mục đích của mình”.

² Khả năng tồn tại (survival anxiety): Chỉ trạng thái khủng hoảng khi chúng ta nhận ra rằng để thành công trong việc gì đó, chúng ta phải thay đổi. (BTV)

Sự không khẳng định có thể đến một cách tự nhiên từ nhiều nguồn mà có thể đe dọa đến sự sống còn của chúng ta: kinh tế, chính trị, công nghệ, pháp lý, đạo đức hoặc đơn giản là một nhận thức rằng chúng ta sẽ không đạt được mục đích. Một nguyên nhân phổ biến của sự không khẳng định ngoài dự tính là các nhà lãnh đạo hành động trái với các giá trị mà chính họ đã nêu ra. Cũng có thể tạo ra sự không khẳng định theo phương pháp có kiểm soát thông qua các công ty liên doanh, các hoạt động lãnh đạo theo kế hoạch hoặc bằng cách tạo ra một cuộc khủng hoảng giả.

Khi mọi người chấp nhận sự cần thiết phải thay đổi, họ đối mặt với nỗi sợ hãi rằng họ có thể không học được các kỹ năng mới và những thái độ ứng xử cần thiết hoặc họ có thể mất vị thế hay một phần bản sắc của mình. Schein gọi hiện tượng này là sự lo lắng về học hỏi (learning anxiety).

Schein cho rằng để thay đổi thành công thì sự lo ngại về khả năng tồn tại phải lớn hơn sự lo lắng về học hỏi, và để làm được điều này, “phải giảm sự lo lắng về học hỏi chứ không phải tăng sự lo ngại về khả năng tồn tại”. Nhiều lãnh đạo và quản lý đã phạm sai lầm khi cố gắng tạo ra sự thay đổi bằng cách gia tăng sự lo ngại về khả năng tồn tại. Điều này tạo ra môi trường đầy sợ hãi khiến các nhân viên phải dành nhiều năng lực để tránh bị đổ lỗi, né tránh trách nhiệm hoặc làm nhiều trò không hay ho gì.

Công cụ hệ thống hiệu quả nhất trong giảm sự lo ngại về khả năng tồn tại mà chúng ta biết đến là Kata Cải tiến, được đề cập trong Chương 6. Phương pháp này được thiết kế để mọi người học các kỹ năng mới và những trải nghiệm những ý tưởng mới một cách an toàn trong quá trình theo đuổi các mục tiêu đã xác định rõ ràng và có thể đo lường được của tổ chức. Điều quan trọng trong việc xây dựng một nền văn hóa hiệu năng cao là phải có một môi trường mà các sai lầm được coi là cơ hội học hỏi để xây dựng các hệ thống và quy trình có thể giúp giảm tác độngcủa các sai lầm trong tương lai.

Tạo cho mọi người cảm giác được an toàn khi thất bại

Quan điểm của tổ chức về thất bại, dù đó là trong một nỗ lực thay đổi hay đơn giản chỉ là một quyết định, là điều quan trọng đối với việc xây dựng một tổ chức linh hoạt và thích ứng. Giáo sư Russell L. Ackoff, một nhà lý luận về tổ chức, lưu ý: “Chính cách đối xử của chúng ta với sai sót là yếu tố mang đến sự ổn định và ngăn cản những thay đổi quan trọng.” Nếu mọi người được nhắc nhở rằng mắc lỗi là điều tệ hại và bị trừng phạt vì những sai sót thì kết quả tất yếu là họ sẽ né tránh việc đưa ra các quyết định rủi ro.

Trong một hệ thống thích ứng phức tạp như doanh nghiệp chẳng hạn, không ai có được thông tin hoàn hảo cả. Mọi quyết định sẽ đều có những hậu quả ngoài ý muốn và có thể làm rõ nguyên nhân khi nhìn lại sự việc, tuy nhiên lại gần như không thể lường được trước khi sự việc diễn ra. Bất cứ khi nào xảy ra thất bại, sẽ có người phải chịu trách nhiệm. Tuy nhiên, chúng ta nên thành thật và tự hỏi: “Nếu ở trong hoàn cảnh đó, thì liệu mình có đưa ra quyết định tương tự không?” Thường thì câu trả lời sẽ là “có”.

Thay vì trách phạt, chúng ta phải bảo đảm rằng mọi người có thông tin cần thiết để đưa ra các quyết định hiệu quả, tìm cách hạn chế ảnh hưởng tiêu cực có thể do các quyết định gây ra và nghiêm túc học hỏi từ những sai lầm đó. Ví dụ, các nhà quản lý và lãnh đạo trong công ty của bạn phản ứng như thế nào đối với các thất bại? Liệu những lỗi này có dẫn đến việc họ tìm kẻ tội đồ, phán xét hay điều tra?

Hành vi thường thấy ở các tổ chức có văn hóa hiệu năng cao là việc phân tích nguyên nhân nhưng không đổ lỗi sau mọi sự cố hay vụ việc. Mục đích của những phân tích đó là nhằm cải tiến hệ thống để khi gặp những tình huống tương tự trong tương lai, mọi người có trong tay nhiều thông tin và công cụ tốt hơn để sử dụng và hạn chế những tác động tiêu cực.

Khi bắt đầu mọi bước phân tích, mỗi người tham gia nên đọc to những từ sau, được gọi là Chỉ dẫn Hồi cứu Cơ bản (Retrospective Prime Directive): “Với bất kể những gì chúng ta khám phá, chúng ta đều hiểu và thực sự tin rằng mọi người đã làm việc của mình một cách tốt nhất có thể, với những hiểu biết, kỹ năng, năng lực, nguồn lực và tình hình lúc đó.” Việc phân tích cần tập trung vào mục đích:

◆ Mô tả và giải thích về việc sự cố đã diễn ra như thế nào, theo quan điểm và cái nhìn của những người liên quan và bị ảnh hưởng, bao gồm bảng liệt kê chuỗi sự kiện theo dòng thời gian và các yếu tố cấu thành sự cố.

◆ Rút kinh nghiệm (các đề xuất, cách khắc phục, danh mục kiểm tra, cập nhật hệ thống runbook³…) để ngăn ngừa, phát hiện và phản ứng tốt hơn nhằm cải thiện khả năng xử trí các sự cố tương tự trong tương lai.

3 Runbook là các lệnh mà quản trị viên trên hệ thống thực hiện. (BTV)

Việc phân tích sự cố không nên chỉ tìm cách xác định một nguyên nhân gốc rễ duy nhất. Nếu nghĩ rằng một sự cố duy nhất là nguyên nhân của thất bại thì đã hiểu sai về bản chất của các hệ thống thích ứng phức tạp. Các chuyên gia về vấn đề an toàn Sidney Dekker, Erik Hollnagel, David Woods và Richard Cook chỉ ra:

Cách hiểu của chúng ta về việc các sự cố xảy ra như thế nào đã trải qua sự phát triển mạnh mẽ trong thập kỷ qua. Lúc đầu các sự cố được coi là sự khép lại của một chuỗi các sự kiện (mà “lỗi của con người” được xem là nguồn gốc hoặc yếu tố cấu thành). Quan điểm này hiện đang dần được thay thế bằng một quan điểm mang tính hệ thống, theo đó các sự cố xuất phát từ sự phức tạp trong các hoạt động của con người trong một bối cảnh tổ chức và kỹ thuật cụ thể. Những hoạt động này thường nhắm vào ngăn ngừa các sự cố nhưng cũng liên quan đến các mục tiêu khác (sản lượng, sản xuất, hiệu quả, kiểm soát chi phí). Điều này có nghĩa là mâu thuẫn về mục tiêu có thể xuất hiện, thường là do thiếu nguồn lực (chẳng hạn thời gian, tiền bạc, chuyên môn). Các sự cố nảy sinh từ sự kết hợp của những điều kiện và sự kiện vốn gắn với việc theo đuổi thành công, tuy nhiên trong sự kết hợp này, từng cái đều cần nhưng chỉ đủ khi tập hợp lại với nhau, các điều kiện và sự kiện đó có thể dẫn đến thất bại.

Mọi thất bại đều là kết quả của nhiều sự việc diễn tiến sai lệch – thường là một cách vô hình (Dekker muốn ám chỉ các hệ thống thích ứng phức tạp “lờ đờ trôi dạt đến bến bờ thất bại”. Mọi bước phân tích sự cố cần đưa đến đa dạng các ý tưởng về cải tiến tăng dần. Chúng ta cũng phải lên kế hoạch tiếp tục theo dõi để kiểm thử liệu những cải tiến này đã hiệu quả chưa, sẽ là lý tưởng nếu thực hiện một bài tập mô phỏng một thất bại tương tự, như chúng tôi mô tả trong Chương 14.

KHÔNG THIẾU NGƯỜI TÀI

Trong lĩnh vực công nghệ, chúng ta thường nghe thấy những cụm từ như “thiếu hụt người tài” và khó tìm “người tốt”. Trong phần này, chúng tôi sẽ bóc gỡ những giả định đằng sau những nhận xét này. Chúng ta sẽ xem xét mình có hàm ý gì khi nói về “người tốt” bằng cách nhìn vào một vai trò cụ thể – các kỹ sư phần mềm – và sau đó tiến tới trường hợp chung.

Nhiều người tin rằng có sự khác biệt đến 10 lần giữa các kỹ sư giỏi nhất và tồi nhất. Trên thực tế, “không có nhiều kinh nghiệm thực tế ủng hộ” con số 10 lần này (chỉ đưa ra một cách tượng trưng và nhẹ nhàng). Tuy nhiên, khi bạn đi đến tận cùng của cuộc tranh luận về quan điểm trên, hóa ra vấn đề lại nằm ở giá trị hoặc tính hữu ích của các phép đo lường năng suất cá nhân trong bối cảnh một tổ chức.

Phương pháp đo lường năng suất cá nhân phổ biến nhất là tính sản lượng – thời gian cần để hoàn tất một nhiệm vụ được chuẩn hóa trong điều kiện có kiểm soát. Cách tiếp cận này được đưa ra dựa trên quan điểm của Taylor về công việc, theo đó các nhà quản lý xác định nhiệm vụ cần thực hiện và công nhân cố gắng hoàn thành các nhiệm vụ này càng nhanh càng tốt. Vì vậy, các thông số truyền thống như số dòng mã mỗi ngày và số giờ làm việc được dùng để đo năng suất cá nhân của các kỹ sư phần mềm. Chúng ta sẽ thấy rõ những sai sót trong các phép đo này nếu cân nhắc đến kết quả lý tưởng: lượng dòng mã ít nhất để có thể giải quyết một vấn đề, và việc tạo ra các quy trình chung, đơn giản hóa cùng những tương tác khách hàng giúp giảm tính phức tạp trong các hệ thống IT. Nhân viên có năng suất cao nhất của chúng ta là những người tìm ra cách làm hay để tránh phải viết bất kỳ dòng mã nào.

Trong nhiều tổ chức, sự lo lắng thái quá về khác biệt giữa các cá nhân là điều vô ích. Nếu có điều gì đó mà chúng ta nên học hỏi từ trường hợp NUMMI ở Chương 1 thì đó là sự khác biệt về văn hóa và lãnh đạo. Nhà báo và tác giả Malcolm Gladwell viết rằng: “lầm tưởng về tài năng (talent myth⁴) giả định rằng chính nhân viên là yếu tố giúp cho các tổ chức trở nên thông minh. Thực tế lại thường ngược lại... Rõ ràng, cuộc sống của chúng ta được làm giàu lên nhờ sự sáng suốt của các cá nhân. Các tổ chức không viết nên các cuốn tiểu thuyết và một ủy ban không thể tìm ra được thuyết tương đối. Nhưng các công ty lại vận hành theo các quy tắc khác. Họ không chỉ sáng tạo mà còn thực thi, hoàn thành và điều phối các nỗ lực của nhiều người khác nhau, các tổ chức thành công nhất ở nhiệm vụ đó là những tổ chức mà hệ thống chính là trung tâm”. Như W. Edwards Deming lưu ý: “Một hệ thống tồi sẽ đánh bại một con người tốt vào bất kỳ lúc nào.”

⁴ Talent myth là một khái niệm được Malcolm Gladwell đưa ra trong một bài báo tháng 7 năm 2002 trên tờ The New Yorker; ông bình luận về tiến thuê nhân công và bổ nhiệm trong các hãng và cách mà những gì được định nghĩa là “tài năng” hiểu sai và khiến các hãng hoạt động kém hơn mong mỏi; “tài năng” trong con mắt của các hãng được mô tả là điều gì đó tách biệt với hiệu năng của công nhân, vì vậy người ta không hiểu rõ cách thức và lý do loại “tài năng” này được dùng để bổ nhiệm. (ND)

Môi trường làm việc, cũng như các kỹ năng và năng lực, là yếu tố quyết định tốc độ nắm bắt và giải quyết các vấn đề phức tạp của chúng ta, kỹ năng chính mà vì đó chúng ta vẫn cần con người chứ không phải các cỗ máy. Chúng ta khó có thể đổ lỗi cho mọi người vì sự thất bại trong học hỏi và giải quyết các vấn đề nếu chúng ta hạn chế các cơ hội của họ bằng việc áp dụng hệ thống tổ chức tách biệt, tức là các nhân viên bị tách biệt với nhau và với khách hàng, bằng những chu trình kéo dài làm chậm tiến độ tiếp nhận phản hồi, bằng việc tập trung vào hoàn thành công việc được giao chứ không phải là giành lấy các kết quả khách hàng, và bằng làm việc quá nhiều nên không còn thời gian để kiểm thử các ý tưởng và công nghệ mới hay thậm chí nói chuyện với nhau!

Hiểu rằng văn hóa của một tổ chức có ảnh hưởng lớn đến hoạt động của các cá nhân, vậy chúng ta có nên quan tâm đến các kỹ năng và thái độ cụ thể của các cá nhân? Thay vì tiếp nhận quan điểm “tài khoản ngân hàng” vốn tập trung vào khả năng hiện có của mọi người, điều quan trọng hơn là phải đánh giá khả năng lĩnh hội các kỹ năng mới của họ – đặc biệt trong lĩnh vực công nghệ, nơi mà tri thức và các kỹ năng hữu ích thay đổi rất nhanh.

Giáo sư Tâm lý học của trường Standford, bà Carol Dweck⁵, đã dành nhiều năm nghiên cứu tâm lý của việc học hỏi, phát triển và động cơ. Bà nhận thấy có biện pháp để đánh giá khả năng học hỏi kỹ năng mới của con người. Dweck phát hiện, khả năng học hỏi của chúng ta được quyết định bởi niềm tin vào câu trả lời cho câu hỏi: năng lực của chúng ta là bẩm sinh hay có thể học hỏi được? Chúng ta có thể quan sát, dựa trên thái độ ứng xử của mọi người, để biết được khi nào thì họ rơi vào hai thái cực:

5 Carol Dweck là tác giả cuốn sách Tâm lý học thành công do Alpha Books mua bản quyền và xuất bản năm 2017.

Theo tư duy bảo thủ, các sinh viên tin rằng năng lực cơ bản của họ, trí thông minh, tài năng của họ là những đặc điểm cố định. Họ có những tài năng nhất định và vậy thôi; và rồi các mục đích của họ luôn có vẻ thông minh chứ không bao giờ ngốc nghếch cả. Trong tư duy phát triển (growth mindset), các sinh viên hiểu rằng tài năng và năng lực của họ có thể được phát triển nhờ nỗ lực, giáo dục và sự kiên trì. Họ không nhất thiết nghĩ rằng mọi người đều giống nhau hay bất kỳ ai cũng có thể là Einstein, nhưng họ tin rằng ai cũng có thể trở nên thông minh hơn nếu họ nỗ lực cải thiện điều đó.

Dweck đã chứng minh qua nhiều thực nghiệm cho thấy tư duy của chúng ta định đoạt cách thức chúng ta quyết định các mục đích và phản ứng với thất bại, niềm tin của chúng ta vào nỗ lực và các chiến lược và thái độ của chúng ta trước thành công của người khác (Hình 11-3). Tư duy của chúng ta đặc biệt quan trọng khi đề cập đến thái độ nhìn nhận sự thất bại. Người có tư duy cố định sợ thất bại vì họ tin rằng thất bại sẽ khiến người khác thấy được những hạn chế của mình, còn người có tư duy phát triển thì không ác cảm như vậy vì họ coi thất bại là cơ hội để học hỏi và phát triển các kỹ năng mới.

Tin tốt là chúng ta có thể thay đổi niềm tin, điều được chứng minh qua một trong những thực nghiệm thú vị nhất của Dweck. Công trình của Dweck chỉ ra rằng nếu chúng ta khen thưởng vì nỗ lực mọi người bỏ ra để giải quyết các vấn đề mà họ gặp phải thì họ sẽ dần chuyển sang tư duy phát triển. Ngược lại, nếu chúng ta khen ngợi vì năng lực triển khai các kỹ năng hiện có của mọi người, chúng ta có thể tạo ra tư duy cố định. Điều này có ý nghĩa quan trọng đối với các nhà quản lý và bộ phận nhân sự, đặc biệt khi đánh giá hiệu năng của nhân viên.

Bạn có thể chắc chắn rằng hành vi và thái độ của mọi người trong tổ chức, tức là văn hóa của tổ chức, ảnh hưởng đến tư duy của các cá nhân và khả năng học hỏi của họ. Như vậy, văn hóa tổ chức quyết định không chỉ năng suất và hiệu năng của các nhân viên mà cả khả năng tiếp nhận các kỹ năng mới và thái độ, quan điểm của họ về thất bại và thách thức mới và mục tiêu của họ. Xác định cho mọi người những mục đích lớn để đòi hỏi họ phải học hỏi các kỹ năng mới, trong khi vẫn hỗ trợ, giúp huấn luyện, cho họ thời gian dự trữ⁶ để giảm sự lo lắng về học hỏi cũng như xây dựng một nền văn hóa có sự phối hợp được tưởng thưởng và thất bại dẫn đến việc rút kinh nghiệm và cải tiến chứ không phải đổ lỗi. Tất cả đều nhằm nuôi dưỡng tư duy phát triển trong nhân viên và phải là mục tiêu chính của việc thay đổi tổ chức.

⁶ Thời gian dự trữ (Slack time): Chỉ lượng thời gian mà một nhiệm vụ có thể được trì hoãn và không khiến nhiệm vụ khác bị trì hoãn theo hay ảnh hưởng tới ngày hoàn thành dự án. (BTV)

Công trình của Dweck cho chúng ta biết rằng thực tế có những người chơi thuộc “nhóm A” và “nhóm B”. Những người chơi nhóm A đơn giản là những người có tư duy phát triển mà khi tham gia nhóm, họ sẽ tìm cách làm cho nhóm thành công và nỗ lực tiếp thu những kỹ năng mới trong quá trình làm việc. Trái lại, những người có tư duy cố định – thuộc nhóm B – là rào cản lớn nhất đối với việc thay đổi tổ chức và cải tiến liên tục. Đây là kiểu người phản bác thử nghiệm vì cho rằng các giải pháp của những tổ chức, cá nhân khác “không thể hiệu quả ở đây”. Họ cũng có xu hướng tuyển dụng những người mà họ cho là kém hơn mình để tránh thách thức vị thế và bản sắc của họ. Mặc dù những người như thế vẫn có khả năng thay đổi tư duy, nhưng họ cũng có thể phá nát những nỗ lực nhằm thay đổi văn hóa và kìm chân các nhóm có hiệu năng cao. Để giảm sự lo lắng về học hỏi trong các nỗ lực thay đổi, cần phải công khai rằng tổ chức sẽ ủng hộ và dành nguồn lực để giúp nhân viên tiếp thu các kỹ năng mới, rằng không ai mất việc cả nếu họ sẵn sàng học hỏi còn những ai muốn rời đi thì sẽ nhận được một gói trợ cấp hào phóng.

Hình 11-3. Sơ đồ về hai kiểu tư duy theo quan điểm của Dweck

Cuối cùng, trách nhiệm quan trọng nhất của các lãnh đạo trong một tổ chức là phải phục vụ văn hóa của tổ chức, thể hiện qua cách mà họ đối xử với người khác. Chẳng hạn, Dweck cho rằng Steve Jobs sở hữu tư duy phát triển đối với khả năng của riêng ông nhưng lại có tư duy cố định với người khác: “Ông muốn họ phải hoàn hảo, họ sợ hãi mỗi khi phải đến gặp ông và bị ông phủ nhận chứ không được tán thành”.

CÁCH TUYỂN DỤNG CỦA GOOGLE

Công trình của Dweck đòi hỏi chúng ta phải suy nghĩ lại về việc tuyển dụng. Chúng ta không nên thuê nhân viên mà chỉ dựa trên những kỹ năng họ đang sở hữu, điều vô cùng thiển cận trong ngành công nghiệp phần mềm, nơi mà công nghệ và các kỹ năng cần thiết thay đổi rất nhanh. Chúng ta cũng không nên sử dụng những bài toán quá phức tạp hoặc các kết quả kiểm tra − những tiêu chí mà Laszlo Bock, Phó Chủ tịch Cấp cao về hoạt động con người của Google, xem là “vô giá trị trong tuyển dụng..., chẳng giúp tiên đoán được bất cứ điều gì”. Google đã tiến hành nhiềunghiên cứu về những gì tạo nên một quy trình tuyển dụng hiệu quả trong lĩnh vực công nghệ. Ba tiêu chí hàng đầu là:

• Năng lực học hỏi, bao gồm năng lực “xử lý tại chỗ” và “xâu chuỗi các mẩu thông tin rời rạc lại với nhau”.

• Sự lãnh đạo, “cụ thể là phong cách lãnh đạo mới so với phong cách truyền thống. Lãnh đạo truyền thống là, có phải bạn từng là chủ tịch của câu lạc bộ cờ vua? Có phải bạn từng là phó giám đốc bán hàng? Bạn leo lên vị trí đó nhanh cỡ nào? Chúng tôi không quan tâm. Cái chúng tôi quan tâm là, khi gặp vấn đề và là thành viên của nhóm, thì bạn có tự tin tham gia và lãnh đạo nhóm khi cần không. Tương tự như vậy, bạn có lùi lại và từ bỏ vai trò lãnh đạo để người khác làm việc đó không? Một điều quan trọng để trở thành một nhà lãnh đạo hiệu quả trong môi trường này là bạn phải sẵn sàng từ bỏ quyền lực”.

• Tư duy. “Những người thông minh và thành công ít khi gặp khó khăn, và vì vậy họ không học được cách học hỏi từ thất bại... Thay vào đó, họ lại phạm những lỗi quy kết, tức là khi có điều gì tốt đẹp thì đó là vì tôi là một thiên tài; còn nếu có điều gì tồi tệ thì đó là vì ai đó là kẻ ngốc hoặc tôi đã không nhận được đủ nguồn lực hoặc thị trường.”

Bock tiếp tục nhận thấy rằng những người thành công nhất tại Google “sẽ có một vị trí vững chắc. Họ sẽ tranh luận gay gắt. Họ sẽ có quan điểm quá khích. Nhưng rồi bạn nói, tình hình mới là thế này, và họ sẽ đi, Oh, tốt, điều đó thay đổi mọi thứ; bạn nói đúng.” Điều này được phản ánh trong lời khuyên của Paul Saffo, Giám đốc Viện

Nghiên cứu Tương lai Palo Alto: “Để đối phó với một tương lai bất trắc và tiếp tục tiến lên, mọi người nên có “những quan điểm mạnh mẽ, nhưng chỉ nắm giữ chúng một cách yếu ớt”.

Chiến lược tuyển dụng của Google rất khoáng đạt vì nó mở ra phạm vi rất rộng cho các ứng viên có khả năng. Thay vì tìm kiếm những “chú sóc tím⁷” với đúng những kỹ năng và kinh nghiệm cần thiết cho công việc, chúng ta nên tìm những người có thể nhanh chóng tiếp nhận các kỹ năng cần thiết và sau đó đầu tư vào một môi trường cho phép họ làm như vậy.

7 Purple squirrel là thuật ngữ tuyển dụng mô tả một ứng cử viên với đúng tiêu chuẩn về giáo dục, kinh nghiệm, phẩm chất đáp ứng hoàn hảo yêu cầu của công việc. (ND)

Phát triển tài năng

Vấn đề “thiếu nhân tài” được giải quyết bằng cách xây dựng một môi trường mà ở đó mọi người có thể học hỏi từ công việc và tuyển dụng những người có tư duy phát triển. Đầu tư vào phát triển đội ngũ nhân viên là một trong số ít cơ hội mà các doanh nghiệp có để tạo ra lợi thế cạnh tranh so với các doanh nghiệp khởi nghiệp (những lợi thế khác bao gồm nghiên cứu, phát triển và sự theo đuổi lựa chọn ở Đường chân trời 3, như đã đề cập ở Chương 2). Có nhiều cách để doanh nghiệp đầu tư vào con người:

Giúp nhân viên xây dựng và bổ sung các kế hoạch phát triển cá nhân Để giúp nhân viên làm chủ sự phát triển cá nhân và bảo đảm rằng các nhà quản lý biết cách giúp họ, điều cần thiết là các nhân viên, các nhà quản lý và những người cung cấp cho họ thông tin phản hồi phải hiểu được mục đích nghề nghiệp của nhân viên. Xây dựng và bổ sung thường xuyên một kế hoạch phát triển cá nhân đơn giản là nền tảng cho phát triển đội ngũ nhân viên.

Tách biệt đánh giá hiệu năng với đánh giá khen thưởng

Mục đích đánh giá hiệu năng là tạo cơ hội để nhân viên nhận được những phản hồi về sự tiến bộ trong thực hiện các mục đích phát triển cá nhân của mình, bổ sung các mục đích và thảo luận về chúng với người quản lý trực tiếp của mình. Kết hợp đánh giá hiệu năng với đánh giá khen thưởng, đặc biệt là việc thực hiện đánh giá nhân viên theo kiểu phân loại tỷ lệ⁸ cứng nhắc là phương pháp dựa trên ý tưởng lỗi thời về động cơ bên ngoài, theo đó các nhân viên được khuyến khích cạnh tranh chứ không phải là hợp tác với nhau. Phương pháp này cũng làm giảm mức độ tham gia của nhân viên.

⁸ Phân loại tỷ lệ (stack ranking): Là phương pháp đánh giá nhân viên trong đó đưa một tỷ lệ nhân viên vào từng cấp độ hiệu năng khác nhau mà không quan tâm đến hiệu quả thực tế. (BTV)

Tạo thuận lợi cho phản hồi thường xuyên

Các nhân viên nên chia sẻ những phản hồi không chính thức một cách thường xuyên để giúp nhau tiến đến mục đích cá nhân. Phản hồi tốt là những phản hồi kịp thời, đem lại lợi ích cho người nhận và được sự cho phép của người phản hồi. Trong một quy trình chính thức (chẳng hạn trong đánh giá hiệu năng, khiển trách chính thức hoặc phỏng vấn khi thôi việc), không nên để cho ai nghe thấy những phản hồi mà họ chưa nhận được một cách không chính thức.

Cho phép nhân viên tiếp cận các nguồn ngân sách huấn luyện

Các nhân viên học hỏi thông qua nhiều kênh khác nhau và cần có thể dễ dàng tiếp cận với những nguồn ngân sách có thể giúp họ mua sách, tham dự các buổi hội thảo và huấn luyện hoặc tham gia vào các hoạt động khác giúp họ tiến tới các mục đích phát triển cá nhân. Điều kiện chi tiêu nên phóng khoáng nhất có thể nhưng phải nằm trong giới hạn các quy định thuế liên quan.

Dành thời gian cho nhân viên theo đuổi các mục đích của mình Nhiều tổ chức đổi mới thường dành thời gian để nhân viên làm bất cứ những điều gì mà họ muốn. Hãng 3M cho phép nhân viên của mình dành 15% thời gian cho các dự án cá nhân từ năm 1948. Giấy ghi chú chỉ là một trong những cải tiến có được nhờ sáng kiến này. Trong Thư IPO⁹ của nhà sáng lập năm 2004, Sergey Brin và Larry Page của Google viết: “Chúng tôi khuyến khích các nhân viên, ngoài các dự án thường xuyên, dành 20% thời gian để làm những gì mà họ nghĩ là sẽ có lợi nhất cho Google. Điều này thúc đẩy họ sáng tạo và đổi mới hơn. Chúng tôi đã đạt được rất nhiều bước tiến quan trọng bằng cách này. Ví dụ, ý tưởng về AdSense cho nội dung và Google News đều được hình thành trong “20% thời gian” này. Nhiều dự án rủi ro và thất bại đã dạy cho chúng tôi những bài học. Những dự án khác thì thành công và trở thành các mảng kinh doanh hấp dẫn”.

9 Initial Public Offering (IPO): Chào bán cổ phần ra công chúng lần đầu. (BTV)

Norman Bodek kể một câu chuyện về việc Taiichi Ohno đóng cửa một kho hàng tại một chi nhánh của Toyota: “Hãy bỏ kho hàng này đi, một năm nữa tôi sẽ trở lại và xem! Tôi muốn thấy kho hàng này trở thành một xưởng chế tạo máy và mọi người đều đã được đào tạo làm thợ máy.” Bodek cho biết, mệnh lệnh của Ohno đã được thực hiện và trong vòng một năm, kho hàng đã được thay thế bằng một xưởng chế tạo máy và các công nhân đã được đào tạo lại. Theo chính sách tiêu chuẩn của doanh nghiệp Nhật Bản hậu Thế chiến II này về việc bảo đảm việc làm trọn đời cho nhân viên, Toyota kỳ vọng tái đào tạo nhân viên để họ có thể đảm nhiệm nhiều công việc khác nhau trong sự nghiệp của mình. Các nhân viên tại Toyota hiểu rằng một phần công việc của họ là phải học hỏi các kỹ năng mới. Toyota đưa ra các khóa huấn luyện và sự hỗ trợ cần thiết cho việc này, giúp loại bỏ rất nhiều những lo lắng về học hỏi vốn là rào cản nghiêm trọng nhất đối với việc xây dựng một tổ chức học hỏi và không ngừng thay đổi. Điều quan trọng nhất là khi được đối xử bằng sự tôn trọng và được trao cơ hội để theo đuổi quyền tự chủ, làm chủ và mục đích, mọi người rất nhiệt tình trong việc tạo ra giá trị. Mức độ hài lòng của nhân viên trong công việc chính là điềm báo tốt nhất về hiệu năng của tổ chức.

Loại bỏ những thành kiến ngầm

Một yếu tố quan trọng khác dẫn đến tình trạng “thiếu người tài” trong lĩnh vực công nghệ là một số lượng lớn những người có trình độ quyết định không bước chân vào lĩnh vực này hoặc sớm bỏ nghề. Hãy nhìn vào các nhóm công nghệ của bạn để thấy rằng có ít người không phải da trắng và đặc biệt là rất ít phụ nữ. Chúng ta biết rằng “sự khác biệt giới tính sinh học trong khả năng thiên bẩm về toán học và khoa học là rất nhỏ và gần như không tồn tại” và cũng không có sự khác biệt như thế giữa các chủng tộc, vậy đâu là nguyên nhân của sự thiếu vắng các thành phần này?

Một số nghiên cứu về các quy trình tuyển dụng nhằm tuyển dụng nhân sự dựa trên năng lực trên toàn cầu đã chỉ ra rằng thành kiến giới tính ngầm tác động mạnh mẽ đến việc từ chối những người phụ nữ có trình độ phù hợp. Trong một nghiên cứu được tiến hành năm 2012, các nhà nghiên cứu tiếp cận 127 giáo sư vật lý, hóa học, sinh học trên toàn nước Mỹ. Họ đưa cho các giáo sư hồ sơ của một sinh viên khoa học chưa tốt nghiệp muốn xin vào vị trí một nhà quản lý phòng thử nghiệm khoa học. Hồ sơ thì giống nhau nhưng với tên của nam hoặc nữ một cách ngẫu nhiên. Những người tham gia được yêu cầu đánh giá “năng lực và khả năng tuyển dụng cũng như mức lương và mức hỗ trợ họ muốn dành cho sinh viên đó”. Kết quả nghiên cứu được thể hiện trong Hình 11-4. Có lẽ phát hiện thú vị nhất là tất cả các giáo sư, cả nam và nữ, đều thể hiện thành kiến như nhau, cho thấy rằng đó không phải là thành kiến cố ý hay rõ ràng mà được “hình thành bởi những thành kiến ẩn hoặc vô tình do tiếp xúc thường xuyên với niềm tin văn hóa phổ biến cho rằng phụ nữ kém năng lực hơn”. Các nghiên cứu khác cũng cho thấy kết quả tương tự ở các lĩnh vực khác và đối với khía cạnh chủng tộc.

Hình 11-4. Tác động của thành kiến giới tính ngầm đến việc tuyển dụng

Những thành kiến ngầm này không chỉ nằm trong phạm vi việc tuyển dụng hoặc giới tính. Những thành kiến ngầm và sự thiếu công bằng trong tiếp cận các nguồn lực xảy ra ở mọi giai đoạn đời sống giáo dục và việc làm của chúng ta, dẫn đến sự thống trị của nam giới da trắng trong các lĩnh vực khoa học, công nghệ, cơ khí và toán học (STEM). Một cuộc khảo sát đại diện với 19.000 người tại Mỹ trong giai đoạn 2001 và 2006 do Viện Level Playing Field Institute tiến hành phát hiện ra rằng chi phí hằng năm của các doanh nghiệp Mỹ dành cho việc thay thế tự nguyện các nhà quản lý và chuyên gia xuất phát từ sự không công bằng nói riêng là 64 tỷ đô-la. Người được khảo sát nêu ra những hành vi sau: sự thô lỗ, các đồng nghiệp ở cùng vị trí hoặc ở vị trí cao hơn nhưng lại có trình độ thấp hơn hoặc ít kinh nghiệm hơn, những người tranh công của bạn, được giao những công việc thường được xem là thấp hơn vị trí công việc, cảm giác bị lạc lõng trong nhóm, và làm việc theo kiểu rập khuôn.

Chúng ta có thể làm được gì với các vấn đề này? Dưới đây là tập hợp một số chiến lược đã được chứng minh là có ích. Để tìm hiểu sâu hơn, hãy tham vấn Freada Kapor Klein trong cuốn Giving Notice: Why the Best and Brightest are Leaving the Workplace and How You Can Help them Stay (tạm dịch: Tại sao những người giỏi nhất và thông minh nhất rời bỏ nơi làm việc và cách giữ chân họ).

Bảo đảm lương thưởng công bằng

Việc so sánh chính xác các cá nhân là điều không thể, vì vậy hãy xem xét trả lương theo vị trí công tác. Hãy so sánh mức lương trung bình trả cho người da trắng trong một vị trí công tác cụ thể (chẳng hạn các chuyên gia phân tích trải nghiệm người dùng hoặc các kỹ sư cao cấp) với mức lương trung bình của những người thuộc các nhóm có ít đại diện. Sửa chữa bất kỳ sự thiếu nhất quán nào mà bạn phát hiện ra. Còn quy trình đánh giá khen thưởng hằng năm của Netflix tuân theo một quy tắc đơn giản: lương của mọi nhân viên được điều chỉnh theo “tốp đầu của thị trường” bằng việc bảo đảm rằng họ được trả lương “nhiều hơn [bất kỳ công ty nào khác] có thể trả; nhiều bằng mức chi phí cho một sự thay thế; nhiều bằng mức chúng ta sẽ bỏ ra để giữ chân họ nếu họ nhận được lời đề nghị hấp dẫn hơn từ một nơi khác”. Nếu được thực hiện một cách toàn diện, cách làm này sẽ có hiệu quả trong khắc phục sự không công bằng đối với các nhóm bất lợi trước đây.

Xây dựng các điều kiện mục tiêu cho việc tuyển dụng và đề bạt Phương pháp Kata Cải tiến có thể và nên được sử dụng như một phần của nỗ lực nhằm gia tăng tính đa dạng. Các điều kiện mục tiêu để tuyển dụng và đề bạt các nhóm ít đại diện là một ví dụ về một cách hợp lý để sử dụng công cụ này. Một doanh nghiệp lớn muốn tăng số lượng phụ nữ đảm nhận các vị trí quản lý cấp cao. Để tránh những cáo buộc về phân biệt đối xử, họ không đưa ra hạn ngạch đối với các vị trí nhưng lại đặt ra một điều kiện mục tiêu về tỷ lệ phụ nữ trong danh sách các ứng cử viên (chẳng hạn 50% ứng cử viên cho một vị trí nào đó phải là phụ nữ). Một cách tiếp cận tương tự có thể được sử dụng trong tuyển dụng và sắp xếp nhóm.

Giám sát thời gian công tác, mức tiến bộ và mức độ hài lòng với công việc Thu thập các dữ liệu về thời gian công tác trung bình của nam giới da trắng với những người thuộc các nhóm ít đại diện. Tìm hiểu xem các nhóm khác nhau thì phải mất bao lâu để có thể được đề bạt. Tìm cho ra trong mỗi nhóm ít đại diện có bao nhiêu phần trăm người là cấp trên của ít nhất một người khác. Phân tích kết quả cuộc khảo sát của bạn về sự hài lòng đối với công việc để tìm ra sự khác biệt về nhân khẩu học. Tỷ lệ nhân viên bỏ việc từ các nhóm ít đại diện cao hơn, thời gian được đề bạt dài hơn và sự hài lòng trong công việc thấp hơn là những chỉ số rõ ràng về những thành kiến ngầm trong tổ chức của bạn.

Thường xuyên đánh giá chính sách, sự tương tác và các quy trình nhân sự

Những thành kiến ngầm không chỉ tác động đến việc tuyển dụng mà ảnh hưởng tràn ngập môi trường công ty. Chỉ cần lấy một ví dụ, phụ nữ có nhiều khả năng là sẽ nhận được những chỉ trích về hiệu năng hơn. Các hình thái tương tự cũng rất rõ ràng trong phản hồi cho các nhóm ít đại diện khác. Điều quan trọng là phải hoạch định chính sách rõ ràng, đề nghị các lãnh đạo thường xuyên công khai thể hiện mong muốn về những hành vi được chấp nhận, và đảm bảo rằng họ sẽ làm gương với những hành vi thích hợp và mọi người sẽ chứng kiến họ hành động khi xảy ra những hành vi không thích hợp. Thuê một chuyên gia bên ngoài để đánh giá các tương tác, chính sách và quy trình nhân sự, đưa ra các khuyến nghị và thường xuyên trở lại với việc giám sát tiến trình thực thi và đánh giá.

KẾT LUẬN

Trong một tổ chức hiệu năng cao, các nhân viên thích thú và tự hào trong công việc thường nhật, còn các nhà lãnh đạo và quản lý thì tận tâm hỗ trợ nhân viên theo đuổi mục đích của tổ chức. Chẳng có tổ chức nào thực hiện điều này một cách hoàn hảo cả và những tổ chức làm tốt nhất đang liên tục làm việc để đạt kết quả tốt hơn.

Để tạo ra môi trường làm việc này, chúng ta phải quan tâm đến hành vi của mọi người trong tổ chức, bắt đầu với các nhà điều hành. Theo quan sát của John Kotter, “đa số nhân viên, khoảng 75% số cán bộ quản lý và hầu như tất cả các lãnh đạo hàng đầu, cần tin rằng những thay đổi lớn là điều thiết yếu”. Bản chất của tư duy tinh gọn là phải hiểu được rằng đây là điều đúng đắn, lúc nào cũng vậy, chứ không chỉ trong một cuộc khủng hoảng. Thay đổi, cải thiện và phát triển chính là thói quen của một tổ chức tinh gọn thực sự.

Có thể thay đổi văn hóa bằng những việc làm thận trọng, tái lặp và có ý thức của mọi người trong tổ chức. Các nhà lãnh đạo và quản lý phải tạo thuận lợi cho những việc này bằng cách đầu tư cho phát triển nhân viên và tạo ra những điều kiện để mọi người hợp tác nhằm liên tục cải tiến quy trình, tri thức và giá trị đem đến cho khách hàng. Cuối cùng, điều quan trọng là các nhà lãnh đạo phải gương mẫu thực hiện những hành vi mà họ mong đợi sẽ được phần còn lại của tổ chức chấp nhận. Các lãnh đạo hành động trái với lời nói – đặc biệt là khi vị thế của họ bị đe dọa hoặc trong giai đoạn căng thẳng – sẽ đánh mất lòng tin của mọi người.

Câu hỏi dành cho độc giả:

◆ Tổ chức của bạn có tiến hành khảo sát ẩn danh (ít nhất là định kỳ mỗi năm) để đánh giá sự hài lòng đối với công việc và các chỉ số văn hóa khác không? Các kết quả tổng hợp có được công bố để ước tính sự tiến độ trong quá trình hướng đến các mục tiêu là sự hài lòng đối với công việc, tính đa dạng và sự thay đổi văn hóa thực sự không? Các kết quả có được thảo luận và căn cứ vào đó để hành động không?

◆ Điều gì xảy ra khi việc gì đó diễn tiến sai? Có một quy trình hệ thống nào giúp học hỏi từ các sự cố để cải tiến các hệ thống, hay các nhà quản lý có tập trung vào việc tìm một tội đồ không?

◆ Tổ chức của bạn làm gì để đầu tư vào phát triển nhân viên dài hạn?

◆ Công ty bạn có nhìn nhận sự thay đổi văn hóa là một quá trình liên tục hay chỉ theo sự kiện? Bạn bắt đầu thực hiện các biện pháp nào để chuyển sang mô hình thay đổi liên tục?

◆ Tổ chức của bạn tuyển dụng những người có kỹ năng và kinh nghiệm cụ thể hay những người có khả năng và có thái độ học hỏi các kỹ năng phù hợp nhằm giúp nhóm của họ thành công?

◆ Tổ chức của bạn có đầu tư cho việc giảm và loại bỏ ảnh hưởng lường mức độ tiến bộ của bạn như thế nào?

Chương 12Nắm chắc tư duy tinh gọn trong quản trị, quản lý rủi ro và tuân thủ (GRC)

Mọi điều đều do diễn giải. Cách diễn giải nào thắng thế ở một thời điểm nào đó sẽ trở nên áp đảo, nhưng đó không phải là sự thật.

− FRIEDRICH NIETZSCHE

Niềm tin không chỉ là vấn đề về sự trung thực hay kiên định. Đó là vấn đề của tình hữu nghị và thiện chí. Chúng ta tin cậy những người quan tâm đến lợi ích của chúng ta và không tin tưởng những kẻ làm ngơ trước những mối quan ngại của chúng ta.

− GARY HAMMEL

Chúng tôi thường nghe mọi người nói rằng các nguyên tắc, kỹ thuật và biện pháp Khởi nghiệp Tinh gọn được khuyến nghị trong cuốn sách này, sẽ chẳng bao giờ phù hợp với các doanh nghiệp lớn do vấn đề về quản lý. “Cái này sẽ không đáp ứng được các yêu cầu pháp quy.” “Điều đó không phù hợp với quy trình quản lý thay đổi của chúng tôi.” “Nhóm của chúng tôi không thể truy cập vào các máy chủ hoặc quá trình sản xuất”. Đây chỉ là một vài ví dụ trong nhiều lý do được mọi người đưa ra để bác bỏ khả năng thay đổi cách họ làm việc.

Khi nghe những phản đối này, chúng tôi nhận ra rằng mọi người không thực sự nói về quản lý; họ đang đề cập đến các quy trình được áp dụng để quản lý rủi ro và sự tuân thủ và nhầm lẫn chúng với quản lý.

Giống như bất kỳ quy trình nào khác trong một tổ chức, các quy trình được thiết kế để quản trị, quản lý rủi ro và tuân thủ (GRC) phải vì mục tiêu cải tiến liên tục và đảm bảo sự đóng góp cho giá trị chung.

Có nhiều tổ chức doanh nghiệp lớn áp dụng các biện pháp kỹ thuật tinh gọn và phát triển văn hóa thử nghiệm như chúng tôi đã trình bày trước đó. Các biện pháp này cũng phải tuân thủ pháp quy và được đánh giá như các biện pháp khác. Qua đó, chúng ta mới biết được khi nào thì công việc có thể được hoàn thành.

Trong chương này, chúng tôi muốn hướng dẫn các bạn vượt qua mê cung GRC, đặc biệt khi liên quan đến việc quản lý các khái niệm và biện pháp cần thiết nếu muốn trở thành một doanh nghiệp tinh gọn. Những người không coi GRC là trọng tâm nghề nghiệp của mình đôi khi không hiểu đầy đủ về mảng này, vì vậy chúng tôi giới thiệu một số kiến thức cơ bản giúp các bạn có hiểu biết cơ bản về các nhóm GRC. Với kiến thức đó, sẽ dễ để thảo luận về cách cải tiến các quy trình và kiểm soát của GRC để các nhóm sản phẩm không ngừng khám phá và cải tiến công việc. Chúng tôi dẫn ra một số ví dụ về cách áp dụng các khái niệm và nguyên tắc tinh gọn để cải tiến các quy trình GRC, giúp cải thiện quản lý và giảm rủi ro chung, trong khi vẫn đáp ứng yêu cầu tuân thủ.

Trong toàn chương này, chúng tôi đề cập đến “các nhóm GRC”. Nói rõ hơn là các cuộc thảo luận và các ví dụ chúng tôi đưa ra tập trung vào các nhóm có ảnh hưởng mạnh mẽ đến cách sử dụng công nghệ trong các tổ chức, phổ biến hơn cả là các nhóm quản lý dự án (PMO), kiến trúc kỹ thuật, an ninh thông tin, quản lý rủi ro và tuân thủ cùng các nhóm kiểm toán nội bộ.

TÌM HIỂU QUẢN LÝ, QUẢN LÝ RỦI RO VÀ TUÂN THỦ

Trong phần giới thiệu ở Phần I, chúng tôi nói rõ, trách nhiệm chính của các nhà lãnh đạo là lèo lái tổ chức hướng đến các mục đích và điều chỉnh lộ trình khi cần thiết. Đó là quản lý. Thật không may là trong các tổ chức, thuật ngữ quản lý thường bị hiểu sai và nhầm lẫn với các lý luận, mô hình và quy trình quản lý được thiết kế để đáp ứng nhu cầu của một kỷ nguyên đã qua.

Quản lý là giữ cho tổ chức của chúng ta luôn đi đúng hướng. Đây là trách nhiệm chính của hội đồng quản lý nhưng cũng là trách nhiệm của tất cả mọi người và các thực thể khác làm việc cho tổ chức. Nó đòi hỏi phải áp dụng các khái niệm và nguyên tắc sau ở tất cả các cấp:

Trách nhiệm

Mỗi cá nhân phải chịu trách nhiệm về các hoạt động, nhiệm vụ và quyết định của mình trong công việc hằng ngày và về những ảnh hưởng của các quyết định đó đối với khả năng của toàn tổ chức trong việc đem lại giá trị cho các bên liên quan.

Thẩm quyền hoặc trách nhiệm giải trình

Mọi người trong tổ chức cần hiểu được ai là người có quyền và có trách nhiệm tác động đến hành vi ứng xử và cách vận hành của tổ chức.

Sự rõ ràng

Mọi người ở mọi thời điểm đều có thể nắm được kết quả của tổ chức và các bộ phận của nó dựa trên dữ liệu thực và dữ liệu hiện tại. Các dữ liệu đó giúp định hình các mục đích và mục tiêu chiến lược của tổ chức.

Trao quyền

Tổ chức trao thẩm quyền hành động để cải tiến việc phân phối giá trị đến các bên liên quan với mức độ phù hợp cho những người sẽ chịu trách nhiệm xử lý các kết quả mà quyết định đó đem lại.

Rủi ro là thứ mà chúng ta phải quản lý trước khả năng có điều gì đó không hay xảy ra. Chúng ta quản lý rủi ro hàng ngày, tại nơi làm việc, ở nhà và cả nơi vui chơi. Vì không thể loại bỏ mọi rủi ro, câu hỏi cần được trả lời trong quản lý rủi ro là “Bạn muốn chung sống với những rủi ro nào?” Khi bạn tiến hành các bước đi nhằm giảm nhẹ rủi ro ở một khu vực, tất nhiên bạn sẽ đưa nhiều rủi ro hơn vào một khu vực khác. Một ví dụ điển hình của điều này là việc hạn chế sự tiếp cận phần cứng của nhóm phát triển và buộc họ phải dựa vào một nhóm cơ sở hạ tầng tập trung hóa để thiết lập truy cập và môi trường cho việc kiểm thử hoặc thử nghiệm. Điều này có thể hiệu quả trong việc đạt được mục đích của nhóm hỗ trợ máy chủ là giảm nguy cơ bất ổn trong các hệ thống, nhưng lại làm tăng nguy cơ phân phối chậm vì các nhóm này phải gửi yêu cầu tới các nhóm khác và chờ đợi họ thực hiện các yêu cầu này.

Sự tuân thủ ở đây là tuân thủ pháp luật, các quy định ngành nghề, các hợp đồng ràng buộc về mặt pháp lý và thậm chí các quy chuẩn văn hoá. Mục đích của tuân thủ bắt buộc là nhằm bảo vệ lợi ích của các bên liên quan đối với quyền bí mật về thông tin, an toàn thể chất và đầu tư tài chính. Khi bị ràng buộc bởi luật lệ, quy định hay hoặc hợp đồng thì việc tuân thủ là không thể lựa chọn. Nếu chọn không tuân thủ, chúng ta sẽ gia tăng nguy cơ bị phạt, ngừng hoạt động hoặc tổn hại danh tiếng.Trong những trường hợp nặng, có thể dẫn đến hình phạt tù đối với những hành vi vi phạm sự tuân thủ một cách có chủ ý và có hệ thống.¹

1. COBIT là một chuẩn quốc tế về quản lý IT do ISACA và ITGI xây dựng năm 1996, cung cấp cho các nhà quản lý, những người kiểm tra và những người sử dụng IT một loạt cách đo lường, công cụ đo, các quy trình và các hướng dẫn thực hành tốt nhất để giúp tăng tối đa lợi nhuận thông qua việc sử dụng IT; giúp quản lý và kiểm soát IT trong tổ chức, doanh nghiệp với mục đích là “nghiên cứu, phát triển, quảng bá và xúc tiến các mục tiêu của kiểm soát IT dành cho các nhà quản lý doanh nghiệp và những người kiểm tra áp dụng vào trong các hoạt động công việc. (ND)

QUẢN LÝ HỆ THỐNG (MANAGEMENT) KHÔNG PHẢI LÀ QUẢN LÝ HỆ THỐNG (GOVERNANCE)

COBIT 5 (Kiểm soát các mục tiêu về thông tin và công nghệ liên quan) làm rõ sự khác biệt giữa quản lý và quản trị.

Quản lý hệ thống đảm bảo rằng các nhu cầu, điều kiện và các lựa chọn của các bên liên quan đều được đánh giá để xác định, cân bằng và thống nhất các mục tiêu mà doanh nghiệp cần đạt được; đưa ra định hướng thông qua việc sắp xếp ưu tiên và tiến trình ra quyết định; và giám sát việc thực hiện và tuân thủ các định hướng và mục tiêu đã nhất trí.

Quản lý hệ thống là công việc lập kế hoạch, xây dựng, vận hành và giám sát các hoạt động cho phù hợp với định hướng mà bộ phận quản trị đặt ra để đạt được các mục tiêu của doanh nghiệp.

Ví dụ, quản lý hệ thống liên quan đến việc thiết lập tầm nhìn và mục đích thay đổi công nghệ với tốc độ cho phép doanh nghiệp thành công. Việc này xác định những gì cần được đánh giá để biết liệu chúng ta có đi đúng hướng đến mục đích hay không. Trong khi đó, quản lý hệ thống xác định cách thức để tổ chức đạt được tầm nhìn đó. Trong trường hợp những thay đổi về công nghệ, quản lý hệ thống bao gồm việc cơ cấu các nhóm phân phối, phạm vi của họ và tầm mức họ được trao quyền quyết định. Nó có phải là một quá trình duy nhất, phù hợp với tất cả và được điều khiển từ trên xuống hay không? Hay là các nhóm sẽ được trao quyền tự chủ và quyền ra quyết định mà không phải đợi sự phê duyệt của cấp trên? Quản lý GRC tốt là duy trì được sự cân bằng giữa mức độ kiểm soát cần thiết để ngăn chặn những kết quả tồi tệ và sự cho phép sáng tạo và thử nghiệm để không ngừng cải tiến giá trị đem đến cho các bên liên quan.

Sử dụng “cách tiếp cận tiến hóa” để quản lý rủi ro

Vấn đề mà chúng ta thường phải trải qua khi thực hiện các cấu trúc và quy trình GRC về tuân thủ là cho rằng chúng là những điều đã cố định và “chắc như đá tảng” mà không cần thay đổi, điều chỉnh và cải tiến. Để có quản lý hệ thống tốt, chúng ta phải thay đổi các quy trình GRC theo thời gian nhằm đáp ứng nhu cầu thay đổi của tổ chức và thị trường mà nó tồn tại.

Khi được thực hiện tốt, các quy trình quản lý GRC cải thiện việc phân phối giá trị nhờ quản lý rủi ro hiệu quả. Mục đích là để cải thiện sự giao tiếp trong hệ thống, sự minh bạch và khả năng theo dõi ai đang làm việc gì, khi nào, bằng cách nào và tại sao, cũng như kết quả của công việc đó. Việc này liên quan chặt chẽ với những sản phẩm mà nhóm phân phối đang cố gắng đạt được. Câu hỏi tiếp theo là: tại sao các quy trình GRC lại được coi là những trở ngại đối với việc tìm kiếm biện pháp cải thiện năng suất và giá trị mà chúng ta cung cấp cho khách hàng và tổ chức?

Điều không may là nhiều quy trình quản lý GRC trong doanh nghiệp được thiết kế và thực hiện theo kết cấu chỉ huy và kiểm soát. Chúng có tính tập trung cao và được coi là thuộc phạm vi của các nhóm chuyên gia GRC, những người không chịu trách nhiệm cho các kết quả của các quy trình mà họ đưa ra. Các quy trình và sự kiểm soát mà các nhóm này đưa ra thường dựa trên các khuôn khổ phổ biến mà không tính đến bối cảnh áp dụng và tác động tới toàn bộ chuỗi giá trị của công việc mà chúng ảnh hưởng. Chúng thường không theo kịp với những thay đổi và khả năng công nghệ có thể giúp đạt được kết quả như mong muốn bằng các công cụ gọn nhẹ và đáp ứng tốt hơn. Điều này buộc các nhóm phân phối phải hoàn thành các hoạt động không tạo thêm giá trị chung, gây ra những điểm tắc nghẽn và tăng nguy cơ thất bại chung trong thực hiện phân phối đúng hạn.

ÁP DỤNG CÁC NGUYÊN TẮC TINH GỌN VÀO CÁC QUY TRÌNH GRC

Giống như mọi công việc khác mà chúng tôi đề cập trong cuốn sách này, hành trình áp dụng các nguyên tắc tinh gọn vào các quy trình GRC – và kết quả mà nó đem lại – sẽ khác nhau ở mỗi tổ chức, tùy thuộc vào bản chất và môi trường hoạt động của doanh nghiệp. Không có công thức mẫu nào phù hợp với mọi hoàn cảnh (như các khuôn khổ danh tiếng như ITIL và COBIT đã giải thích).

Tuy nhiên, các nguyên tắc và khái niệm tinh gọn có thể được áp dụng cho bất kỳ quy trình quản lý GRC nào: làm rõ chuỗi giá trị, tăng mức độ phản hồi, nâng cao năng lực học hỏi, trao quyền cho các nhóm, giảm lãng phí và chậm trễ, giảm thiểu khối lượng công việc trong quy trình, tạo ra những thay đổi nhỏ và tăng dần để đạt được kết quả tốt hơn.

Một cách tự nhiên, luôn tồn tại sự căng thẳng giữa các nhóm GRC – được giao nhiệm vụ đề xuất và tư vấn về biện pháp giảm rủi ro và duy trì việc tuân thủ các luật lệ và quy định liên quan – với phần còn lại của tổ chức – những người chỉ muốn hoàn thành công việc càng sớm càng tốt. Dẫu vậy, sự căng thẳng này có thể là điều tốt. Nó kích thích sáng tạo, nhưng sự sáng tạo đó chỉ tốt nếu tất cả các bên liên quan đều biết và phấn đấu để đạt được các mục tiêu chung và được đánh giá theo cùng tiêu chuẩn. Khi sự căng thẳng này là điều xấu, nó dẫn đến sự thiếu hợp tác, không rõ ràng và tuân thủ kém bởi vì các cá nhân và các nhóm bí mật phát triển các biện pháp để né tránh các quy trình GRC. Điều này dẫn đến việc đưa ra các quyết định dựa trên thông tin không đầy đủ hoặc không chính xác và làm suy yếu toàn bộ hoạt động quản lý hệ thống.

Mục đích và mục tiêu của các nhóm GRC thường đem đến nhiều công việc hơn cho tất cả các nhóm. Một số công việc là tốt. Việc quan tâm trực diện đến các rủi ro, các mối đe dọa và việc kiểm soát có thể giúp tránh được nhiều điều đáng tiếc ở những bước cuối cùng hướng đến sản xuất. Chứng minh được rằng chúng ta có các biện pháp kiểm soát phù hợp tại chỗ là điều quan trọng trong quá trình kiểm toán và giúp chúng ta luôn ở trạng thái tuân thủ. Thách thức ở đây là phải tìm ra sự cân bằng chính xác giữa việc kiểm soát để giúp các nhóm tiến nhanh và việc giữ cho những rủi ro liên quan đến sự tuân thủ thấp ở mức chấp nhận được.

Xác định giá trị của các quy trình GRC từ quan điểm khách hàng

Để thu được giá trị từ các quy trình GRC như kiểm soát truy cập, quản lý thay đổi kỹ thuật và chu trình phân phối giải pháp, chúng ta luôn phải bắt đầu bằng việc tạo ra hiểu biết chung về các mục đích, giá trị của tổ chức và kết quả mong đợi của quy trình. Chúng ta cần hiểu được cách mà công việc hằng ngày của chúng ta đóng góp cho các tiêu chí này ở cấp độ tổ chức dù chúng ta thuộc nhóm nào đi nữa. Điều này có nghĩa là các nhóm GRC của chúng ta cần chịu trách nhiệm về kết quả (tốt và xấu) của các hoạt động tuân thủ và quản lý rủi ro cũng như tác động của chúng tới khả năng phân phối kịp thời của các nhóm. Tương tự, các nhóm phân phối sản phẩm cần hiểu được nội dung, ý định và mục đích của các quy trình và sự kiểm soát được thiết lập để phục vụ sự tuân thủ và quản lý hệ thống. Chỉ khi đó thì các nhóm này, thường được coi là làm việc liên mục đích, mới có thể “ngừng tranh đấu một cách ngu ngốc và làm mọi chuyện tốt đẹp hơn”.

Như vậy, các nhóm GRC phải xem mình là thành viên của nhóm phân phối sản phẩm, tìm hiểu về các khả năng công nghệ và kỹ thuật được sử dụng trong kỹ thuật tinh gọn và giúp các nhóm áp dụng chúng để cung cấp bằng chứng về sự tuân thủ mà không gây lãng phí và bế tắc. Đồng thời, toàn bộ nhóm phân phối cần bắt đầu chú ý tới nội dung và những khuôn khổ được các nhóm GRC sử dụng để hiểu chính xác những gì nhóm GRC đang cố gắng đạt được.

Chúng tôi đã chứng kiến sự lãng phí khủng khiếp và căng thẳng ghê gớm giữa các nhóm GRC và các nhóm phân phối bởi nhiều quy trình và biện pháp quản lý của GRC không gắn với cách làm việc của các nhóm. Thông thường, các nhóm GRC tập trung triển khai và đánh giá sự tuân thủ (ví dụ bằng cách hỏi “Mọi người có thực hiện các hoạt động như hướng dẫn của chúng tôi không?”), chứ không quan tâm đến kết quả (“Chúng ta có đang làm những gì giúp đáp ứng sự tuân thủ và tiếp tục phân phối giá trị một cách kịp thời?”).

BÍ QUYẾT

Tránh cách tiếp cận theo kiểu “Nó hẳn sẽ không khủng khiếp nếu” trong quản lý rủi ro

Trong cuốn How to Measure Anything, Douglas Hubbard kể về việc Peter Tippet của công ty CyberTrust² đã trao đổi như sau: Những gì mà ông nhận ra là một kiểu tư duy chủ đạo về [an ninh IT]. Ông gọi đó là cách tiếp cận “nó hẳn sẽ không khủng khiếp nếu...”Trong khuôn khổ này, các chuyên gia bảo mật IT tưởng tượng một sự kiện thảm khốc đặc biệt xảy ra và không cần biết mức độ thảm khốc ra sao nhưng phải tránh được bằng mọi giá. Tippet nhận thấy: “vì mỗi lĩnh vực đều có một ‘nó hẳn sẽ không khủng khiếp nếu…’, nên mọi việc đều cần phải thực hiện. Không có ý thức nào về sự ưu tiên ở đây.”

² CyberTrust là một công ty dịch vụ an ninh được thành lập ở Virginia, Mỹ tháng 11 năm 2004 trên cơ sở sáp nhập hai công ty TruSecure và Betrusted. (ND)

Khi sắp xếp ưu tiên cho công việc trên toàn danh mục, không được giao tấm vé miễn phí nào để những công việc làm giảm “những điều xấu” nhảy vọt lên hàng đầu. Thay vào đó, hãy xác định số lượng các rủi ro bằng cách sử dụng sơ đồ tác động (xem Chương 9) để đánh giá những tác động và xác suất của chúng; sau đó sử dụng Chi phí Trì hoãn (xem Chương 7) để cân bằng các công việc tối giản với những ưu tiên khác. Bằng cách này, chúng ta có thể sử dụng một khuôn khổ kinh tế, thay vì nỗi sợ hãi, sự bất trắc và ngờ vực, để quản lý các rủi ro về an ninh và tuân thủ.

Các nhóm GRC được đánh giá bằng câu hỏi: “Chúng ta có tuân thủ không?”; các nhóm sản phẩm được đánh giá bằng câu hỏi: “Chúng ta có thể phân phối giá trị nhanh như thế nào thông qua việc sử dụng công nghệ?” Cả hai câu hỏi này đều sai bởi vì chúng đánh giá hiệu năng của một nhóm từ góc độ chức năng riêng biệt chứ không phải từ giá trị ròng cho tổ chức. Các nhóm GRC dễ dàng tuân thủ luật lệ khi chính họ được phép đưa ra các quy trình và buộc mọi người thực hiện đầy đủ các bước. Tuy nhiên, khi đánh giá hiệu năng của nhóm mà gắn kết với cấp độ tổ chức, thì trong khi có thể tuân thủ đúng, chúng ta vẫn đưa ra những quyết định hết sức tồi tệ trong phân phối giá trị cho các bên liên quan. Điều này thực sự trớ trêu vì nhiều điều luật và quy định liên quan đều được xây dựng với ý định bảo vệ và cái tiến giá trị đem đến cho các bên liên quan.

CÁC CÁCH TIẾP CẬN DỰA TRÊN QUY ĐỊNH DẪN ĐẾN SÂN KHẤU QUẢN LÝ RỦI RO³

³ Sân khấu quản lý rủi ro (risk management theatre): Chỉ khái niệm về mô hình kiểm soát phổ biến, áp từ trên xuống, gây khó khăn cho người vô tội nhưng người mắc sai phạm lại né tránh được. (BTV)

Khi các nhóm GRC không áp dụng cách tiếp cận dựa trên nguyên tắc mà lại quy định các luật mà các nhóm phải tuân thủ một cách mù quáng, thì kết quả thường thấy sẽ là một sân khấu quản lý rủi ro: một màn hành động tốn kém được thiết kế để quản lý rủi ro nhưng thực tế lại làm tăng xác suất cho những hậu quả tiêu cực ngẫu nhiên.

Tại một doanh nghiệp lớn của châu Âu nơi chúng tôi làm việc, quy trình phê duyệt sự thay đổi như sau: các lập trình viên điền vào biểu mẫu gồm bảy mục và gửi thư điện tử cho Giám đốc Thay đổi ở một nước khác và chờ xem vị giám đốc đó quyết định chấp thuận hay không. Bạn không thể thúc đẩy sự thay đổi đó nếu không được chấp thuận và nếu biểu mẫu không được điền đầy đủ thì sẽ bị gửi lại. Vị Giám đốc Thay đổi đã không thực sự hiểu nội dung của biểu mẫu; trước khi phê duyệt, ông đối thoại với các lập trình viên để xác định rủi ro là gì và liệu các hoạt động tối giản theo kế hoạch có phù hợp hay không. Các lập trình viên biết điều này và dành nỗ lực ít nhất cho việc điền vào biểu mẫu, thường chỉ là thay đổi ngày và tiêu đề của một biểu mẫu cũ và gửi lại như một đề xuất mới. Giám đốc Thay đổi biết các lập trình viên làm như vậy, nhưng không thấy có vấn đề gì miễn là thủ tục hồ sơ được thực hiện sau bức thư đó. Việc này không giúp gia tăng giá trị cho việc quản lý rủi ro, đồng thời còn gây tổn thất cho nhóm khi duy trì sự thay đổi đó. Tuy nhiên, sự tuân thủ đã được đáp ứng thông qua “bằng chứng” được thể hiện trong bảng đề xuất thay đổi. Giá trị thực đã đạt được qua các cuộc đàm thoại và hoàn tất các hoạt động tối giản trước khi sự thay đổi diễn ra.

Khi các nhóm sản phẩm trì hoãn trên sân khấu quản lý rủi ro, phản ứng chung là cho rằng cần áp dụng những khuôn khổ phổ biến như ITIL, COBIT, hoặc các luật, quy định như luật Sarbanes-Oxley⁴. Tuy nhiên, với một số trường hợp ngoại lệ, cả khuôn khổ cũng như luật lệ đều không quy định các quy trình cụ thể. Ví dụ, nhiều người nghĩ rằng mục 404 của luật Sarbanes-Oxley yêu cầu phải phân chia nhiệm vụ1, nên các tổ chức kiểm soát chặt chẽ việc truy cập vào các hệ thống và môi trường IT hiểu được điều này có nghĩa là gì. Trên thực tế, không có mục nào trong đạo luật Sarbanes-Oxley – cũng như trong các quy định SEC (Ủy ban Chứng khoán và Giao dịch Chứng khoán Mỹ) được đưa ra theo đạo luật này – đề cập đến việc phân chia nhiệm vụ cả.

⁴ Luật Sarbanes-Oxley: Là tên một đạo luật liên bang của Mỹ, đặt ra những yêu cầu mới hoặc bổ sung cho tất cả các hội đồng quản trị, quản lý của các công ty đại chúng và các hãng kiểm toán công. (BTV)

Nếu thấy công ty đang chờ đợi bạn thực hiện một quy trình làm ảnh hưởng đến khả năng hoàn thành tốt công việc, bạn cần tìm gặp những người đã xây dựng quy trình đó để trao đổi về nội dung của nó. Hãy trở lại với Yêu cầu Nhiệm vụ đã được thảo luận trong Chương 1 để tạo cơ hội hợp tác, xây dựng quan hệ và phát triển hiểu biết chung. Bạn có thể cảm thấy ngạc nhiên khi phát hiện rằng mình có thể có một cuộc trao đổi hữu ích về cách đáp ứng các mục đích của họ theo một cách khác, hoặc thực sự thấy được liệu công việc của bạn có nằm trong phạm vi các luật hoặc quy định đang được đề cập đến hay không. Nếu họ bảo bạn rằng một số quy định “yêu cầu” phải có một quy trình cụ thể, hãy lịch sự hỏi xem bạn có thể tìm thêm thông tin về yêu cầu đó ở đâu. Trong nhiều trường hợp, các quy định và quy trình GRC nặng nề được đưa ra chỉ đơn giản là sự diễn giải của một người nào đó về những gì được yêu cầu, chứ không bắt buộc theo quy định được đề cập.

LẬP BẢN ĐỒ CHUỖI GIÁ TRỊ, TẠO DÒNG VÀ THIẾT LẬP MỘT HỆ THỐNG KÉO⁵

⁵ Segregation of duties là khái niệm không cho phép một thành viên nào được tham gia giải quyết mọi mặt của nghiệp vụ từ đầu đến cuối. Đây là hoạt động kiểm soát chính nhằm ngăn ngừa gian lận và sai sót. (ND)

Với hiểu biết chung về các quy trình GRC, cùng các mục đích và phương pháp của nhóm phân phối sản phẩm, chúng ta thực sự có thể bắt đầu cộng tác để đạt được các mục đích ở cấp độ tổ chức. Như đã thảo luận trong Chương 7, bản đồ chuỗi giá trị là một công cụ mạnh mẽ có thể được sử dụng để cung cấp cho chúng ta hiểu biết về hiện trạng và xác định các lĩnh vực cần cải tiến. Trong bối cảnh của các quy trình GRC, điều quan trọng là phải đặt chúng lên hàng đầu trong các hoạt động của nhóm phân phối và hiểu được cách mà chúng ảnh hưởng đến khả năng hoàn thành công việc của nhóm.

Nhiều quy trình GRC được thiết kế riêng nhằm áp dụng các biện pháp kiểm soát như phê duyệt bắt buộc, tiếp cận giới hạn, phân chia nhiệm vụ, giám sát và đánh giá hoạt động. Việc kiểm soát này là để làm rõ ai làm việc gì, khi nào và có quyền hạn gì. Quan trọng hơn, những khuôn khổ thường được các nhóm GRC sử dụng để xây dựng các quy trình nhấn mạnh đến việc cải tiến hiệu quả và hiệu năng chung cho tổ chức. Điều không may là nhiều quy trình và biện pháp kiểm soát lại có tác dụng trái ngược hoàn toàn khi chúng được xem xét trong chuỗi giá trị cuối-đến-cuối với phạm vi lớn hơn.

Kiểm soát sai lầm làm nghẽn dòng công việc

Về bản chất, các biện pháp kiểm soát có thể có tính chất phòng ngừa bằng cách dựng lên một rào cản. Ngoài ra, chúng có thể có tính chất khám phá thông qua việc giám sát và nghiên cứu các sự kiện sau khi chúng xảy ra; và xác định phản ứng thích hợp khi phát hiện các trường hợp ngoại lệ tiềm tàng như các lỗi, thiếu sót hoặc các hành động nguy hiểm.

Nhiều người trong chúng ta hiểu nhầm rằng việc kiểm soát phòng ngừa có hiệu quả hơn, rằng nếu chúng ta có thể tạo ra các rào cản hoặc ngăn chặn khả năng hành động của mọi người thì sẽ không xảy ra sự cố. Thực tế là, mọi người cần phải hoàn thành công việc. Nếu bạn cố gắng ngăn họ, nhiều người sẽ tìm ra các phương pháp sáng tạo để làm việc bất kể hàng rào nào đã được dựng lên. Nếu bạn đáp trả bằng cách khóa mọi quy định chặt chẽ hơn thì càng thôi thúc các giải pháp ngầm và sáng tạo hơn nữa, kích động một nền văn hóa tìm kiếm những hành vi rủi ro. Minh chứng cho việc này là các nhóm sẽ chia sẻ ID và mật khẩu người dùng được nâng cấp để truy cập vào các môi trường khác nhau. Sẽ tốt hơn nhiều nếu chúng ta cho phép mỗi thành viên của nhóm truy cập theo ID riêng và sau đó giám sát việc họ sử dụng những đặc quyền đó.

Một hậu quả tệ hại hơn khi áp dụng quá nhiều biện pháp kiểm soát phòng ngừa là các nhóm không còn quan tâm nữa và lựa chọn trạng thái tự động vận hành, từ bỏ mọi nỗ lực để làm mọi việc tốt hơn.

Việc kiểm soát phòng ngừa, khi áp dụng không đúng cấp độ, thường dẫn đến chi phí cao một cách không cần thiết, buộc các nhóm phải:

◆ Chờ một nhóm khác hoàn thành các nhiệm vụ nhỏ nhặt vốn có thể dễ dàng thực hiện khi cần

◆ Nhận được sự chấp thuận từ những nhân vật bận rộn nhưng lại không am hiểu về những rủi ro liên quan đến quyết định đó và vì vậy gây ra những điểm bế tắc

◆ Tạo ra một khối lượng lớn các tài liệu thiếu chính xác và trở nên lỗi thời ngay sau khi được hoàn thành

◆ Đẩy một khối lượng lớn công việc cho các nhóm và các ủy ban đặc biệt để được phê duyệt và xử lý, sau đó ngồi chờ phản hồi

Nếu các biện pháp kiểm soát phòng ngừa không được thực hiện đúng cách và nhất quán, chúng sẽ không còn hiệu quả. Chúng phải được giám sát liên tục để đảm bảo đã được áp dụng đúng và vẫn phù hợp. Nếu không có các hoạt động giám sát và điều chỉnh sau đó thì các biện pháp kiểm soát phòng ngừa sẽ kém hiệu quả hơn so với các biện pháp kiểm soát khám phá được thực hiện tốt như theo dõi thường xuyên, kiểm tra, đánh giá sớm và thường xuyên, và đánh giá kết quả một cách cụ thể, rõ ràng.

Mặc dù dựa vào các biện pháp kiểm soát phòng ngừa có thể tạo cảm giác sai lệch về an toàn, nhưng chúng đặc biệt có giá trị khi áp dụng đúng cấp và là giải pháp tốt nhất trong một số trường hợp. Tuy nhiên, không bao giờ được chỉ áp dụng các biện pháp này mà phải kết hợp với các biện pháp kiểm soát khác và phải luôn cân nhắc tác động của chúng đến khả năng thực hiện công việc của các nhóm.

Do đó, khi chúng ta lập bản đồ giá trị, trong đó đặt các quy trình quản lý lên trước các quy trình của nhóm phân phối, chúng ta cần xem xét cẩn thận tất cả các biện pháp kiểm soát và đặt ra hai câu hỏi:

◆ Mục đích của các biện pháp kiểm soát có đang được đáp ứng không?

◆ Các biện pháp đó có thực sự đóng góp vào hiệu quả và hiệu năng chung của tổ chức không?

Chúng ta cần xem xét cẩn thận mức độ tự chủ trao cho các nhóm. Mục đích là phải có được các quyết định phê duyệt đúng cấp và trao cho các nhóm càng nhiều thẩm quyền càng tốt để khuyến khích các nhóm không ngừng vận động. Điều này liên quan đến việc xác định ranh giới và đảm bảo các nhóm biết cách thức và thời điểm đưa ra các quyết định nằm ngoài thẩm quyền của họ. Chúng ta cũng cần đảm bảo hồ sơ được lưu giữ phù hợp và khi hoàn thành, hãy đảm bảo hồ sơ này có thể truy cập, dễ hiểu và được cập nhật theo yêu cầu, tốt nhất là một cách tự động.

“Tin tưởng, nhưng phải kiểm chứng” là một khái niệm đang được chấp nhận rộng rãi trong các chu trình GRC. Thay vì ngăn các nhóm truy cập vào môi trường và phần cứng để không thể làm bất cứ điều gì tồi tệ, chúng ta cần tin tưởng rằng mọi người đều làm những điều đúng đắn và cho phép họ truy cập, kiểm soát trên các hệ thống và phần cứng mà họ cần sử dụng hằng ngày. Sau đó, chúng ta xác minh để chắc chắn rằng nhóm không lạm quyền thông qua việc phát triển các quy trình giám sát và đánh giá thường xuyên để đảm bảo các ranh giới thiết lập đều được theo dõi và công việc của nhóm luôn tuyệt đối rõ ràng và minh bạch.

GIẢM CÁC VÒNG PHẢN HỒI ĐỐI VỚI CÁC HOẠT ĐỘNG TUÂN THỦ

Đáp ứng sự tuân thủ về An ninh Thông tin đã trở thành cái gai trong mắt nhiều nhóm phân phối. Theo tinh thần của phương pháp phân phối dự án “vụ nổ lớn”, nhóm an ninh xuất hiện vào thời điểm muộn nhất có thể – một vài ngày trước khi đưa sản phẩm ra thị trường – để tiến hành đánh giá mã cuối về những lỗ hổng về an ninh và sự tuân thủ cần thiết.

Cộng đồng An ninh Thông tin hiện nay nhận thấy cách tiếp cận này không hiệu quả. Nhiều sản phẩm quá phức tạp và quá cồng kềnh để có thể thực hiện đánh giá một cách hiệu quả. Thông thường, khi phát hiện được những lỗ hổng hoặc các vi phạm về tuân thủ bằng cách này thì đã là quá muộn để có thể làm được điều gì đó đáng kể. Việc khắc phục những lỗ hổng trong một hệ thống yếu ớt, hoặc chờ đợi những thay đổi, còn rủi ro hơn là cho phép đưa những lỗ hổng đó vào sản xuất, hứa hẹn rằng sẽ khắc phục chúng sau.

Để đáp ứng sự tuân thủ và giảm rủi ro về an ninh, hiện nhiều tổ chức đã đưa các chuyên gia an ninh thông tin vào làm thành viên của các nhóm sản phẩm liên chức năng. Vai trò của họ là giúp nhóm xác định các mối đe dọa an ninh tiềm tàng và mức độ kiểm soát cần thiết để giảm chúng đến mức chấp nhận được. Họ được tham vấn ngay từ đầu và tham gia vào tất cả các khía cạnh của phân phối sản phẩm:

• Tham gia thiết kế nhằm đảm bảo quyền riêng tư và an ninh

• Phát triển các kiểm thử an ninh tự động có thể đưa vào đường ống triển khai.

• Phối hợp các lập trình viên và nhân viên kiểm thử để giúp họ hiểu cách tránh đưa thêm những lỗ hổng phổ biến vào cơ sở mã

• Tự động hóa quy trình kiểm thử các bản vá bảo mật cho các hệ thống

Họ cũng xây dựng môi trường riêng để thực hiện kiểm tra mã bắt buộc và kiểm thử an ninh để chúng không gây trở ngại cho nhóm trong thực hiện các công việc khác khi công việc này đã hoàn thành.

Là thành viên tham gia thực hiện công việc của nhóm, các chuyên gia an ninh thông tin giúp rút ngắn vòng phản hồi về an ninh, giảm rủi ro bảo mật tổng thể cho giải pháp đó, cải thiện khả năng cộng tác và hiểu biết về các vấn đề an ninh thông tin cho các thành viên khác trong nhóm, còn bản thân họ thì học hỏi được nhiều hơn về bối cảnh mã và các biện pháp phân phối.

Mọi người đều thắng.

Khi chúng ta giỏi tạo luồng cho các nhóm hơn bằng cách thay đổi các quy trình quản lý, các nhóm GRC cũng hưởng lợi. Sử dụng các biện pháp kiểm soát được thiết kế trong quá trình phối hợp với các nhóm GRC, các nhóm phân phối sản phẩm có thể đưa các bằng chứng về sự tuân thủ thực sự vào công việc và các công cụ hàng ngày và loại bỏ sân khấu quản lý rủi ro. Tương tự như khi làm với chất lượng chức năng và chất lượng thực hiện, chúng ta đưa bằng chứng về sự tuân thủ vào công việc hằng ngày, như vậy chúng ta không phải tiến hành các đợt thanh tra lớn sau khi phần lớn các công việc đã hoàn thành.

Hiệu ứng ròng⁶ cho các nhóm GRC là họ có thể nắm thông tin về sự tuân thủ của các nhóm phân phối sản phẩm vào bất cứ thời điểm nào mà không làm gián đoạn luồng công việc tổng thể của nhóm, trừ khi xảy ra trục trặc hay việc khó hiểu gì đó. Công tác kiểm toán hằng năm đỡ khó khăn hơn do các nhóm phân phối hiểu mục đích của các biện pháp kiểm soát mà các kiểm toán viên đề nghị và đưa ra được bằng chứng rằng họ đáp ứng được mục đích đó thông qua các quy trình của mình.

⁶ Hiệu ứng ròng (net effect): Thuật ngữ chỉ kết quả/hiệu ứng cuối cùng của điều gì đó. (BTV)

Bằng cách sử dụng một khuôn khổ kinh tế (như Chi phí Trì hoãn, được đề cập trong Chương 7), chúng ta có thể định lượng những thỏa hiệp kinh tế mà chúng ta chấp nhận khi thực hiện các biện pháp kiểm soát nhằm giảm thiểu rủi ro. Điều này cho phép chúng ta ưu tiên công việc GRC so với các loại công việc khác mà chúng ta thực hiện và qua đó giảm lượng công việc bổ trợ cần thực hiện để đảm bảo tuân thủ vào đúng thời điểm cho doanh nghiệp.

NGHIÊN CỨU ĐIỂN HÌNH: TRIỂN KHAI PCI-DSS TẠI ETSY

Etsy là chợ bán đồ cũ và đồ thủ công trực tuyến với tổng doanh thu hơn 1 tỷ đô-la năm 2013. Trong nền văn hóa tin cậy cao của Etsy, các lập trình viên thường đưa trực tuyến những thay đổi của mình. Thực tế, như một bộ phận của các kỹ sư mới gia nhập, các lập trình viên sử dụng hệ thống triển khai tự động để cập nhật thông tin trên trang trực tuyến trong vòng vài ngày đầu tiên. Các kỹ sư cũng được phép thao tác trên các trang đó – và có quyền truy cập – vào tất cả các phần của hệ thống.

Tuy nhiên, vì Etsy xử lý các giao dịch trên thẻ tín dụng, nên phải tuân thủ PCI-DSS, một tiêu chuẩn ngành tương đối khắt khe trong quản lý các hệ thống lưu trữ hoặc truyền dữ liệu chủ thẻ thanh toán (các hệ thống này được gọi là môi trường dữ liệu của chủ thẻ, hoặc CDE). Ví dụ, CDE phải được tách riêng về cơ học và phải có sự phân chia nhiệm vụ cho những người làm việc về các hệ thống trong khuôn khổ CDE.

Việc phân chia bản mô tả vấn đề thường được hiểu (cùng với nhiều điều khác) rằng các lập trình viên không nên truy cập vào cơ sở dữ liệu vận hành và không nên đưa trực tuyến các thay đổi của họ. Cả hai yêu cầu này đều xung đột với cách vận hành của Etsy. Đây là cách họ tiếp cận để tuân thủ tiêu chuẩn PCI-DSS.

1. Giảm thiểu hậu quả của sự tuân thủ cần thiết. Hiểu rằng không có một giải pháp tuân thủ chung nào cho tất cả và các hệ thống kiến trúc phân biệt các mối quan tâm liên quan đến các yêu cầu tuân thủ khác nhau.

Văn hóa kỹ thuật chủ đạo của Etsy được tối ưu hóa để thúc đẩy tốc độ đổi mới. Tuy nhiên, việc xử lý thẻ tín dụng là một lĩnh vực mà yêu cầu bảo mật dữ liệu người dùng là tối quan trọng. Etsy nhận thấy rằng các bộ phận khác nhau trong hệ thống của họ có những mối quan tâm khác nhau và cần phải được đối xử khác biệt.

Quyết định quan trọng nhất về kiến trúc của Etsy là tách môi trường CDE khỏi phần còn lại của hệ thống, hạn chế phạm vi của các quy định PCI-DSS vào một mảng riêng biệt và ngăn không để chúng “rò rỉ” ra toàn bộ các hệ thống sản xuất. Các hệ thống cấu thành CDE được tách riêng (và được quản lý theo cách khác) khỏi các môi trường còn lại của Etsy ở các cấp độ hạ tầng cơ sở vật lý, mạng, mã nguồn và lô-gíc. Hơn nữa, CDE được xây dựng và vận hành bởi một nhóm liên chức năng chịu trách nhiệm hoàn toàn về CDE. Một lần nữa, điều này giúp giới hạn của các quy định PCI-DSS trong phạm vi nhóm này.

2. Thiết lập và hạn chế phạm vi tác động của các khuôn khổ và các quy định.

Luôn bắt đầu bằng câu hỏi: “Những thay đổi nhỏ nhất chúng ta có thể làm với kiến trúc và văn hóa lý tưởng của chúng ta là gì, trong khi vẫn bảo đảm tuân thủ các quy định bắt buộc?” Sau đó áp dụng cách tiếp cận tái lặp và tăng dần để thực hiện và khẳng định giá trị của những thay đổi đó.

Ví dụ, mặc dù PCI-DSS yêu cầu phân chia nhiệm vụ, nhưng không ngăn cản nhóm CDE liên chức năng hoạt động cùng nhau trong một không gian duy nhất. Khi các thành viên của nhóm CDE muốn thúc đẩy một sự thay đổi, họ đưa ra một thẻ đề nghị để lãnh đạo công nghệ phê duyệt; nếu không thì quá trình cam kết và triển khai mã sẽ hoàn toàn tự động như với môi trường Etsy chủ đạo. Không hề có sự tắc nghẽn và chậm trễ vì sự phân chia nhiệm vụ được thực hiện cục bộ: sự thay đổi được phê duyệt bởi một người khác chứ không phải người thực hiện thay đổi.

3. Sử dụng các biện pháp kiểm soát bù⁷

⁷ Biện pháp kiểm soát bù (compensation control): Còn gọi là biện pháp kiểm soát thay thế, là cơ chế được xây dựng để thỏa mãn yêu cầu cho một biện pháp an ninh vốn được coi là khó thực hiện hoặc phi thực tế trong thời điểm hiện tại. (BTV)

Điều quan trọng là phải tôn trọng kết quả mà các quy định đang nỗ lực đạt được trong khi hiểu rằng có nhiều cách để đạt được những kết quả đó. Ví dụ, PCI-DSS cho phép các tổ chức thực hiện “kiểm soát bù” – một giải pháp được thiết kế để tạo ra cùng một kết quả, theo đó những yêu cầu hợp pháp về kỹ thuật kinh doanh ngăn cản việc áp dụng một biện pháp kiểm soát cụ thể.

Trong trường hợp PCI-DSS, bạn nên trao đổi với nhân viên kiểm soát an ninh có năng lực (QSA) và ngân hàng thương nhân⁸ để thảo luận các lựa chọn thay thế tiềm năng cho các biện pháp kiểm soát gây ảnh hưởng về kỹ thuật hoặc nghiệp vụ không thể chấp nhận được. Chẳng hạn, đường ống triển khai được mô tả trong Chương 8 và được Etsy sử dụng đã cung cấp một tập hợp các biện pháp kiểm soát bù hiệu quả có thể thay thế cho việc phân chia nhiệm vụ trong các hệ thống khác của họ.

⁸ Ngân hàng thương nhân (accquiring bank): Hay còn gọi là ngân hàng của người bán, tức ngân hàng xử lý tín dụng hoặc các hoạt động thanh toán thay mặt cho một thương nhân. (BTV)

Lợi thế của việc áp dụng các nguyên tắc tinh gọn và phân phối liên tục trong phát triển sản phẩm là điều đó cho phép thực hiện cách tiếp cận thích ứng và suôn sẻ trong quản lý rủi ro. Vì làm việc theo nhóm nhỏ và có thể theo dõi từng thay đổi đối với các hệ thống từ khi đăng ký đến khi triển khai nên chúng ta có thể định lượng rủi ro của từng thay đổi và quản lý nó một cách thích hợp.

Cách tốt nhất để đạt được các mục tiêu của GRC tốt là gắn sự tuân thủ và quản lý rủi ro với hoạt động hằng ngày của các nhóm sản phẩm, bao gồm các hệ thống, thiết kế và kiểm thử trải nghiệm người dùng. Khi các tổ chức từ bỏ kết cấu chỉ huy và kiểm soát, các nhóm GRC áp dụng cách tiếp cận phối hợp trong quản lý rủi ro, chúng ta bắt đầu coi các nhóm như các cố vấn và các chuyên gia đáng tin cậy trong lĩnh vực chuyên môn của họ. Đối với nhiều nhóm GRC, điều này đòi hỏi một sự thay đổi lớn trong vai trò, trách nhiệm và hành vi của họ trong một tổ chức doanh nghiệp. Đây là sự chuyển đổi từ vai trò chỉ đạo sang vai trò của một thành viên nhóm, người cũng được đánh giá trên cơ sở kết quả hoàn thành nhiệm vụ như với nhóm sản phẩm chứ không chỉ xét trên quan điểm tuân thủ.

KẾT LUẬN

Quản lý tốt đòi hỏi mọi người phải tập trung khám phá các biện pháp cải thiện giá trị và cung cấp thông tin chính xác để đưa ra các quyết định. Chúng ta bắt đầu với vai trò lãnh đạo và chỉ đạo của Hội đồng Quản lý và Ban Điều hành, và dựa vào khả năng của nhân viên, những người có tinh thần trách nhiệm cao khi đưa ra các quyết định trong công việc. Quản lý tốt cũng cần một nền văn hóa cởi mở, tin cậy và minh bạch.

Các cấu trúc và quy trình GRC phải được các nhóm GRC và các nhóm sản phẩm phối hợp xây dựng hằng ngày để phân phối giá trị cho khách hàng. Khi hiểu được ý định của các điều luật và các quy định phải tuân thủ, các nhóm GRC của chúng ta có thể hợp tác với các nhóm sản phẩm để xác định những cách tiếp cận cục bộ phù hợp nhất với cải tiến việc phân phối giá trị. Chúng ta bắt đầu bằng việc khám phá, với các nhóm GRC, cách giảm thiểu những tác động tiêu cực của việc dựa vào các biện pháp kiểm soát hạn chế thông qua việc sử dụng sáng tạo kiến trúc hệ thống, cải thiện tiến trình, giới hạn phạm vi, áp dụng các biện pháp kiểm soát bù và thúc đẩy các công nghệ mới. Sau đó chúng ta có thể khai thác khả năng học hỏi của mình để liên tục cải tiến các quy trình nhằm bảo đảm cả quản lý tốt hơn và kết quả tốt hơn cho tất cả các bên liên quan.

Câu hỏi dành cho độc giả:

◆ Các nhóm sản phẩm của bạn nhìn nhận các quy trình GRC hiện tại của bạn như thế nào? Tổ chức của bạn tham gia vào sân khấu quản lý rủi ro đến mức độ nào?

◆ Các nhà lãnh đạo có những hành động gì để phát triển sự hiểu biết chung về nội dung và khuôn khổ GRC trong toàn tổ chức?

◆ Liệu các cấu trúc GRC của bạn (các chính sách, tổ chức và quy trình) có cản trở các nhóm sản phẩm cải tiến quy trình hoặc yêu cầu họ phải xin phê duyệt đối với bất kỳ một sự thay đổi quy trình nào? Nếu có, làm thế nào mà bạn có thể hỗ trợ các nhóm cải tiến các quy trình của họ trong khi vẫn duy trì sự tuân thủ?

◆ Bạn làm thế nào để các nhóm GRC phối hợp với các nhóm phân phối sản phẩm như là các thành viên đáng tin cậy của nhóm trong suốt quá trình tạo ra giá trị?

Chương 13Phát triển quản lý tài chính để thúc đẩy đổi mới sản phẩm

Quá tuân thủ các nguyên tắc về ngân sách không hẳn đã làm nên các quyết định hay.

− EMILY OSTER

Ngay bây giờ, công ty của bạn đã có các quy trình kinh doanh trên nền tảng Internet thế kỉ XXI và các quy trình quản lý giữa thế kỷ XX. Tất cả đều được xây dựng dựa trên các nguyên tắc quản trị của thế kỷ XIX.

− GARY HAMEL

GIỚI THIỆU

Ở nhiều doanh nghiệp lớn, các quy trình quản lý tài chính (FMP) được xây dựng theo mô hình dự án. Điều này là một trở ngại đối với cách tiếp cận đổi mới dựa trên sản phẩm. Các nhóm nhỏ tương đối dễ dàng làm việc và cộng tác với nhau. Tuy nhiên, trong quy mô doanh nghiệp, cuối cùng chúng ta cũng sẽ chạm ngưỡng, sự phát triển bị chặn đứng bởi các FMP tập trung, cứng nhắc dẫn dắt quá trình phân phối và cung ứng, làm hạn chế các lựa chọn đổi mới ở quy mô phù hợp. Chúng ta sẽ giải quyết một số vấn đề do các FMP gây ra, đặc biệt chú trọng vào quá trình ngân sách. Chúng tôi nhấn mạnh rằng để vượt qua những rắc rối mà tổ chức bạn đang trải qua do các quy trình quản lý tài chính gây ra, bạn sẽ cần sự trợ giúp của nhóm tài chính. Hãy bắt đầu bằng việc xây dựng mối quan hệ hữu hảo với họ và phối hợp làm việc để cải thiện kết quả cho khách hàng và doanh nghiệp.

Việc nhận rõ sự tác động qua lại giữa tất cả các quy trình quản lý, các hành vi bất lợi và những rào cản mà chúng gây ra cho cải tiến liên tục và đổi mới là điều cần thiết để thực hiện tinh gọn thành công. Sẽ khó khăn khi phải từ bỏ những niềm tin vốn tồn tại đã lâu rằng kiểm soát tập trung và mạnh mẽ sẽ mang lại hiệu quả đáng giá. Nó có thể đã phục vụ chúng ta trong một kỷ nguyên ít phức tạp hơn và các tiến bộ kỹ thuật diễn ra chậm hơn, tuy nhiên, hiện nó đang tạo ra rào cản ngăn chúng ta thích nghi nhanh chóng với các cơ hội đang nổi lên. Trong bối cảnh đó, các nguồn lực và nỗ lực cần thiết để thu thập thông tin, liên lạc, và giám sát các quy trình tập trung và cứng nhắc là điều quan trọng nhất mà không tổ chức nào khác cần đạt được. Đồng thời, quy trình ngân sách tập trung cao khuyến khích hành vi cạnh tranh, chứ không phải là hợp tác. Điều này phản tác dụng đối với sự đổi mới, tập trung vào làm việc theo nhóm.

Nhiều tổ chức đa quốc gia lớn đã tự chuyển mình bằng cách buông bỏ niềm tin lâu năm rằng chỉ huy và kiểm soát là cách tốt nhất để quản lý các quy trình tài chính của mình. Để đọc thêm về chủ đề này, chúng tôi giới thiệu các cuốn sách Beyond Budgeting (tạm dịch: Trên cả lập ngân sách) và Implementing Beyond Budgeting (tạm dịch: Thực hiện trên cả lập ngân sách) và trang web của tổ chức Beyond Budgeting Round Table.

TẬP TRUNG QUÁ MỨC VÀO CÁC YÊU CẦU TÀI CHÍNH LÀM GIẢM SỰ ĐỔI MỚI

Lập kế hoạch, dự toán ngân sách, dự báo và giám sát là cần thiết để xác định thành công, đặc biệt là cam kết của chúng ta với các cổ đông. Các quy định và tiêu chuẩn sửa đổi hoặc tương đối mới, chẳng hạn như Sarbanes-Oxley và Tiêu chuẩn Báo cáo Tài chính Quốc tế, đã tăng cường nhu cầu tập trung và kiểm soát các quy trình này. Tuy nhiên, ý nghĩa của các quy định này là nhằm nâng cao tính minh bạch và rõ ràng trong báo cáo tài chính cũng như khả năng đưa ra các quyết định tốt hơn. Trong khi đó, kiểm soát tập trung và ra quyết định thông qua ngân sách hằng năm có thể dễ dàng đem đến kết quả ngược lại.

Trong chương này, chúng tôi xem xét những phương pháp quản lý tài chính tổ chức trong các doanh nghiệp thường được nhận định là cản trở sự đổi mới:

◆ Đưa ra các quyết định kinh doanh dựa vào chu kỳ ngân sách tập trung hằng năm, trừ những trường hợp ngoại lệ. Đây là việc kết hợp các hoạt động dự báo, lập kế hoạch và giám sát vào một quy trình tập trung duy nhất, được thực hiện mỗi năm một lần, và kết quả là đầu ra của các hoạt động quan trọng này không thể đạt mức tối ưu.

◆ Coi khả năng đạt các mục tiêu ngân sách là một chỉ số chính để đánh giá hiệu năng của cá nhân, nhóm và tổ chức nói chung, điều vốn chỉ cho biết mọi người đóng vai trò như thế nào trong tiến trình chứ không thể hiện kết quả mà họ đạt được trong năm qua.

◆ Đưa ra các quyết định kinh doanh dựa trên cấu trúc báo cáo tài chính về vốn chứ không phải chi phí hoạt động. Điều này hạn chế khả năng đổi mới bằng cách bắt đầu bằng một sản phẩm khả thi tối thiểu, sau đó phát triển dần dần hoặc có thể bị loại bỏ bất cứ lúc nào. Mô hình báo cáo chi phí CapEx/OpEx¹ chủ yếu dựa vào tài sản hữu hình và dựa trên dự án; nó không tận dụng tốt việc sử dụng thông tin vào thử nghiệm, học hỏi và liên tục cải tiến sản phẩm theo thời gian.

¹ Chi phí đầu tư/Chi phí hoạt động. (BTV)

Khi sử dụng kết hợp những phương pháp này, chúng ta buộc phải ấn định thời gian cho những quyết định kinh doanh chủ chốt và các kế hoạch hoạt động hằng năm để tối ưu hóa các chu kỳ báo cáo tài chính, làm hạn chế thời điểm và cách thức tiến hành đổi mới kinh doanh trong tổ chức. Chúng không đồng hành với khả năng và nhu cầu phân phối giá trị liên tục cho khách hàng của chúng ta. Các chương trình làm việc lớn, cồng kềnh và được cấp vốn đầy đủ thường đem lại những giá trị đáng ngờ và kéo dài bất tận, trong khi các cơ hội mới và không tiên lượng trước cứ thế trôi qua vì không còn ngân sách để khám phá và kiểm thử các giả thiết của chúng ta về chúng. Thay vì dành thời gian để đổi mới, chúng ta lại dành cho quản lý và báo cáo “ngân sách”.

Giải phóng bản thân khỏi chu kỳ ngân sách thường niên

Các quy trình lập ngân sách tập trung thường được sử dụng để lập kế hoạch, dự báo, giám sát và báo cáo tình hình tài chính và hiệu quả hoạt động chung của một tổ chức. Chúng dẫn dắt mọi thứ, từ báo cáo mục tiêu doanh thu đến lập kế hoạch thuế và phân bổ nguồn lực. Tuy nhiên, trong bối cảnh phát triển sản phẩm, chu kỳ ngân sách thường niên truyền thống có thể dễ dàng:

◆ Làm giảm tính minh bạch về chi phí phân phối giá trị thực tế – các trung tâm chi phí chức năng tiến hành phân bổ chi phí trên cơ sở các nguồn tiền mà không xem xét trọn vẹn quy trình sản xuất sản phẩm.

◆ Không cho phép những người trực tiếp thực hiện công việc tham gia tiến trình ra quyết định – ban quản lý cấp trên chịu trách nhiệm xây dựng và chỉ định các mục tiêu chi tiết.

◆ Hướng chi phí khỏi việc tạo ra giá trị do bắt buộc thực thi các quy trình phê duyệt, theo dõi và giải trình chi phí hết sức nặng nề.

◆ Đánh giá hiệu năng theo khả năng làm hài lòng ông chủ hoặc đầu ra của sản xuất – chứ không phải theo kết quả của khách hàng thực tế – bằng cách khen thưởng những người đạt mục tiêu ngân sách cho dù chi phí tổng thể và dài hạn là bao nhiêu đi nữa.

Tuy nhiên, nhiều doanh nghiệp lớn đã tìm ra giải pháp thay thế cho quy trình ngân sách tập trung truyền thống để đạt được mục tiêu quản lý tài chính tốt. Hình 13-1 nhấn mạnh tầm quan trọng của việc phân tách các mục tiêu của lập ngân sách và đề xuất những cách tiếp cận khả thi.

Hình 13-1. Những cách tiếp cận nhằm đạt được các mục đích lập ngân sách, được sự cho phép của Bjarte Bogsnes, tác giả cuốn Implementing Beyond Budgeting: Unlocking the Performance Potential

Hãy chấm dứt việc nhầm lẫn việc quản lý tài chính tốt với “Ngân sách”

Tôi ghét ngân sách thường niên giống như việc phải hứng chịu sự tra tấn của hàng nghìn tia nắng mặt trời.

− KHUYẾT DANH

Ngân sách cần được coi là tổng số tiền dành riêng hoặc cần thiết cho một mục đích: “Mức tối đa mà chúng ta có thể chi cho hoạt động này là bao nhiêu?” Ngân sách không xác định những gì chúng ta thực sự sẽ làm – nó là chiến lược. Nó không phải là một kế hoạch được xây dựng để đạt được một chiến lược, cũng không dự báo hoặc đánh giá thành công của chúng ta trong việc cung cấp giá trị cho khách hàng.

Khi chúng ta gói tất cả các hoạt động thiết yếu này vào quy trình dự toán ngân sách, chúng ta sẽ mất tập trung.

Có ngân sách là điều tốt, đặc biệt là khi chúng ta đã đặt ra một số mục tiêu tài chính dài hạn cho mình. Nhưng những căng thẳng về tài chính có thể là chất xúc tác mạnh mẽ cho sự sáng tạo, hợp tác và đổi mới. Đặc biệt trong giai đoạn khám phá, chúng ta có thể thúc đẩy sự đổi mới nếu chủ đích giảm ngân sách của một số bộ phận hoặc các sản phẩm và cho phép các nhóm quyết định cách sử dụng hiệu quả nhất các quỹ hiện có, như chúng tôi đã mô tả trong Phần II của cuốn sách này. Tuy nhiên, cách tiếp cận này sẽ không hiệu quả nếu chúng ta chỉ đơn giản là giảm ngân sách và nói cho nhóm biết mục tiêu của họ là gì và làm thế nào để đạt được chúng.

Theo nguyên tắc phụ trợ được mô tả trong Chương 10, trách nhiệm quản lý các quỹ cần được phân bổ, phải được giao cho cấp thích hợp thấp nhất – nói chung là những người đang thực hiện công việc. Chúng ta vẫn cần cung cấp cho các nhóm những khái niệm rõ ràng về những gì bị cấm nhưng họ cần được tin tưởng và được trao cơ hội đưa ra quyết định. Như mô tả trong cuốn Implementing Beyond Budgeting (tạm dịch: Thực hiện trên cả ngân sách), khi gã khổng lồ hóa dầu Borealis của châu Âu sử dụng cách tiếp cận này, họ nghĩ rằng chi phí sẽ tăng lên. Nhưng thực tế, chi phí lại giảm. Mặc dù Borealis là tập đoàn có vị thế và đã sẵn sàng cho sự thay đổi với một nền văn hóa ủng hộ xu hướng này, CFO Bjarte Bogsnes vẫn cho rằng có được kết quả này là nhờ làm rõ hơn những nhân tố phát sinh chi phí bằng việc áp dụng tốt nguyên tắc kế toán dựa trên hoạt động: những người chịu trách nhiệm về các hoạt động phát sinh chi phí phải báo cáo về tình hình tài chính của họ và các nhóm phải có trách nhiệm quản lý chi phí tốt hơn.

Tình trạng vỡ kế hoạch nặng nề là hệ quả tất yếu của quy trình ngân sách tập trung nếu chúng ta đưa ra kế hoạch dự toán tài chính chi tiết cho năm sau và cứng nhắc thực hiện kế hoạch đó. Nỗ lực phát triển những loại kế hoạch này là một sự lãng phí về thời gian và nguồn lực, bởi phát triển sản phẩm cũng cần nhiều sự khám phá không kém quá trình thực hiện. Chi phí sẽ thay đổi, cơ hội mới sẽ xuất hiện và một số công việc theo kế hoạch lại không đạt được kết quả mong muốn trên thực tế. Trong thế giới toàn cầu hóa ngày nay, khi mà công nghệ phát triển nhanh chóng và ngày càng nhiều yếu tố khó lường thì thật ngu ngốc khi nghĩ rằng có thể thực hiện thành công các kế hoạch được lập chuẩn xác đến từng chi tiết.

Một cách tiếp cận hay hơn là đặt ra các mục đích dài hạn từ cấp cao, quản lý cẩn thận những yếu tố có thể dự đoán trong tương lai gần và liên tục điều chỉnh các kế hoạch ngắn hạn để tiến gần hơn các mục tiêu đặt ra. Chúng ta có thể áp dụng cách tiếp cận này bằng cách thực hiện triển khai chiến lược được mô tả trong Chương 15. Triển khai chiến lược áp dụng siêu phương pháp Kata Cải tiến được trình bày trong Chương 6 và phổ biến phương pháp này trong toàn bộ tổ chức theo Yêu cầu Nhiệm vụ được mô tả trong Chương 1. Bjarte Bogsnes trình bày một cách tiếp cận tương tự gọi là “Biến tham vọng thành hành động” trong cuốn Implementing Beyond Budgeting.

BÍ QUYẾT

Thay thế ngân sách thường niên bằng các dự báo cuốn chiếu (rolling forcast)

Dự báo cuốn chiếu là công cụ hữu ích giúp cải thiện việc lập kế hoạch tài chính và giảm phụ thuộc vào ngân sách. Khi một giai đoạn được hoàn thành, thì giai đoạn tiếp theo được dự báo gối tiếp để lúc nào cũng có thể bao quát một khoảng thời gian dài tương đương trong tương lai. Việc dự báo vào cuối giai đoạn không cung cấp nhiều chi tiết nhưng bao gồm các hạng mục chi phí đã nắm được với dự toán về chi phí trong các hạng mục này trong khoảng thời gian được đề cập. Trong dự báo cuốn chiếu, sự chú ý được dồn vào tương lai gần dựa trên những thông tin chính xác hiện có. Chúng ta không nên dành nhiều thời gian cho việc chi tiết hóa các hạng mục có thể thay đổi một cách khó lường trong tương lai.

Khi áp dụng cách tiếp cận này, hãy nhớ rằng các dự báo không nhằm xác định các mục tiêu hoặc quản lý các nguồn lực. Trừ khi bạn sử dụng một cách tiếp cận như triển khai chiến lược hoặc “Biến tham vọng thành hành động” để đặt ra các mục tiêu và quản lý nguồn lực và hiệu năng, bạn sẽ có được một ngân sách cuốn chiếu chứ không phải dự báo cuốn chiếu, điều mà Bogsnes mô tả là “năng động hơn đôi chút nhưng lại làm tăng khối lượng công việc lên 4 lần”.

Khi phân tách các hoạt động cần để quản lý tài chính tốt từ quy trình ngân sách hằng năm, chúng ta sẽ cải thiện được khả năng am hiểu tình hình hiện tại. Chúng ta tập trung tạo dựng một mạch xuyên suốt trong tiến trình ra quyết định và thực hiện những điều chỉnh cần thiết để đáp ứng các mục tiêu đã đặt ra. Cần chuyển đổi từ câu hỏi: “Tôi có được cấp tiền để làm những gì tôi được yêu cầu phải làm không?” sang câu hỏi: “Việc này có thực sự cần thiết không?”

Tách các quyết định cấp vốn khỏi chu kỳ tài khóa thường niên

Việc sử dụng chu kỳ tài khóa thường niên để xác định phân bổ nguồn lực khuyến khích một nền văn hóa cản trở năng lực thực nghiệm và đổi mới của chúng ta. Nó làm tăng chi phí cho các hoạt động vô ích và các ý tưởng không đem lại giá trị. Chúng ta phải hiểu rằng việc đổi mới cần một khoản chi phí liên tục mà không thể xác định và lập kế hoạch đầy đủ trong năm trước đó. Chúng ta cần các quy trình gọn nhẹ và thực tế để cấp vốn cho hoạt động đổi mới và phải kiên quyết ngừng thực hiện bất cứ công việc nào được đánh giá là sẽ không tạo ra kết quả mong muốn.

Khi một quy trình thường niên là con đường duy nhất để được cấp vốn cho các hạng mục cụ thể hoặc các sáng kiến mới, thì gần như không thể thay đổi được phương hướng và không phản ứng được khi xuất hiện những thông tin mới. Thay vào đó, hàng năm chúng ta phải dành rất nhiều nỗ lực để trình bày kế hoạch kinh doanh tốt nhất nhằm có được kinh phí nhiều nhất có thể, thay vì thành thật về những gì chúng ta nghĩ là mình cần. Trong tất cả các đề xuất cấp vốn được nêu ra trong sự kiện thường niên này, chỉ những đề xuất được trình bày thuyết phục nhất mới được thông qua mà không phải thay đổi. Những đề xuất còn lại sẽ bị cắt giảm hoặc để lại chờ xem xét trong năm tới, vì vậy sẽ làm tăng chi phí trì hoãn.

Thay vào đó, một số công ty đang áp dụng một phương pháp gọi là phân bổ nguồn lực năng động được thể hiện trong Hình 13-2. Cách tiếp cận này tạo ra các điểm chốt thường xuyên hơn nhằm kiểm tra các quyết định cấp vốn và góp phần giảm mức độ rủi ro của từng quyết định. Do được đưa ra trên cơ sở các bằng chứng thực nghiệm nên tất cả các quyết định đều dễ thực hiện hơn. Khi thực hiện đúng, khả năng tiếp cận nguồn vốn sẽ mở rộng đến nhiều nhóm hơn, thường xuyên hơn, ít rủi ro hơn và mang lại kết quả tốt hơn. Như vậy, chúng ta khuyến khích đổi mới nhiều hơn và giảm rủi ro tài chính liên quan đến các sáng kiến lớn.

Hình 13-2. Phân bổ nguồn lực năng động, được sự cho phép của Bjarte Bogsnes, tác giả của cuốn Implenting beyond budgeting

Mô hình phát triển sản phẩm mà chúng tôi thảo luận trong cuốn sách này phù hợp với phương pháp phân bổ nguồn lực năng động. Khi có ý tưởng mới, chúng ta phải bắt đầu từ giai đoạn khám phá. Chi phí khám phá ý tưởng đó có thể được đo lường bằng chi phí hoạt động của nhóm sản phẩm. Ranh giới được xác định: bạn có thể có một nhóm nhỏ trong khoảng thời gian xác định, và số tiền chi tiêu tối đa là X.

Khi nhóm đã có bằng chứng rằng ý tưởng sẽ mang lại giá trị, chúng ta có thể cấp thêm vốn để chuyển sang giai đoạn khai thác. Trong suốt Đường chân trời 3, chúng ta hướng tới sử dụng Nguyên tắc Lựa chọn để quản lý các khoản đầu tư của mình (xem Chương 2 để biết thêm về ba đường chân trời và nguyên tắc lựa chọn). Mục đích của chúng ta là đầu tư nguồn lực hạn chế vào một số lựa chọn khả thi với nhận thức rằng nhiều lựa chọn sẽ thất bại, nhưng một vài lựa chọn khác sẽ đem lại thành công lớn.

Các nhóm thành công trong việc thoát khỏi giai đoạn khám phá và mở rộng quy mô sẽ bắt đầu thực hiện cải tiến liên tục, như mô tả trong Chương 6, nhằm không ngừng loại bỏ sự lãng phí trong quy trình phân phối. Điều quan trọng là phải tránh “khen thưởng” những nhóm đạt được các cải tiến về hiệu năng bằng cách giảm chi phí hoạt động, cắt giảm quy mô nhóm hoặc giảm liên kết nhóm. Việc này ngay lập tức sẽ triệt tiêu động lực của các nhóm và giết chết tư duy đổi mới. Thay vào đó, nhóm nên dành nhiều thời gian hơn để khám phá các ý tưởng mới mà không cần dẫn chứng tài liệu, đánh giá và phê duyệt – miễn là họ duy trì được hiệu năng cao và giữ chi phí trong giới hạn cho phép. Bằng cách tạo ra các quy trình gọn nhẹ để thông qua các khoản ngân sách bổ sung nhằm hỗ trợ khai thác các ý tưởng, chúng ta sẽ duy trì được đà phát triển.

Bằng cách sử dụng kết cấu sản phẩm chứ không phải kết cấu dự án, việc tính lợi nhuận và thua lỗ trên từng sản phẩm hoặc dịch vụ sẽ dễ dàng hơn nhiều. Chúng ta có thể tính toán chi phí phân phối và vận hành một sản phẩm hoặc dịch vụ chỉ đơn giản thông qua chi phí hoạt động của nhóm xây dựng và vận hành nó. Điều này giúp bạn dễ dàng biết được khi nào chi phí liên quan đến một sản phẩm hoặc dịch vụ vượt quá giá trị nó đem lại hoặc khi nào chúng ta không đạt được biên lợi nhuận kỳ vọng. Khi chúng ta muốn xây dựng các tính năng được sử dụng cho nhiều sản phẩm, chúng ta có thể sử dụng Chi phí Trì hoãn để đưa ra một quyết định đầu tư (xem Chương 7).

Khi tuyên bố giá trị và chi phí phát triển, hỗ trợ của một sản phẩm thay đổi theo vòng đời của nó, chúng ta có thể thay đổi thành phần của nhóm chịu trách nhiệm vận hành và nâng cao chất lượng sản phẩm đó. Cuối cùng, khi sản phẩm bắt đầu đem lại giá trị âm, chúng ta nên ngừng sản phẩm đó càng sớm càng tốt. Thông thường, cần phải có một khoản đầu tư để ngừng các sản phẩm và dịch vụ – và một lần nữa, Chi phí Trì hoãn có thể được áp dụng để ra quyết định. Việc này có thể đòi hỏi sự vào cuộc của các nhà điều hành: Chúng ta biết rằng có một Công ty Fortune 500 từng xét thưởng cho các phó giám đốc dựa trên số lượng dịch vụ ngừng hoạt động trong năm nhằm giảm tính phức tạp của hệ thống và khuyến khích đổi mới.

Đối với các sáng kiến nhỏ hơn, đơn giản hơn và ít rủi ro, quy trình đánh giá và phê duyệt nên gọn nhẹ hơn so với các sáng kiến phức tạp ở cấp độ doanh nghiệp. Song song với đó, chúng ta cần một quy trình liên tục và các tiêu chí xác định khi nào thì nên ngừng cấp vốn. Có thể phân cấp hoạt động đánh giá và giám sát bằng cách tạo ra các nhóm cấp bộ phận có trách nhiệm báo cáo về kết quả của những quyết định cấp vốn của họ. Các báo cáo này có thể tổng hợp vào báo cáo cấp độ doanh nghiệp. Chúng ta vẫn muốn duy trì sự kiểm soát tập trung từ cấp cao đối với các sáng kiến doanh nghiệp lớn hơn, tuy nhiên phải ở mức rất ít ở bất kỳ thời điểm nào. Xem Bảng 13-1 về một số mô hình cấp vốn mẫu.

Bảng 13-1. Mô hình cấp vốn mẫu

Loại bỏ chu kỳ ngân sách thường niên mang tính tập trung hóa cao độ không có nghĩa là chúng ta né tránh trách nhiệm quản lý tài chính tốt. Nhiều công ty lớn toàn cầu, trong đó có Handelsbanken, Maersk và Southwest Airlines, đã xúc tiến các hành trình thoát khỏi các ngân sách tập trung lớn và thực hiện quản lý chi phí bằng các phương tiện khác. Các công ty này bắt đầu bằng cách phân công trách nhiệm tài chính cho các đơn vị cơ sở và các đơn vị kinh doanh riêng rẽ:

◆ Ban quản lý cấp cao không đặt mục tiêu cho tất cả các chi phí và doanh thu cho năm tài khóa tới.

◆ Các quyết định kinh doanh quan trọng không dựa trên ngân sách.

◆ Các nhóm và các cá nhân không được đánh giá bằng chi tiêu trong ngân sách được cấp.

Mọi người vẫn có các mục tiêu và chịu trách nhiệm cải thiện giá trị mà họ cung cấp. Tuy nhiên, các mục tiêu này không phải cấp cao nhất giao phó mà là do các nhóm tự đặt ra trên cơ sở gắn kết với các mục đích và mục tiêu ở cấp độ tổ chức.

Khám phá các nguyên tắc kế toán dựa trên hoạt động

Việc sử dụng các nguồn lực phải gắn trực tiếp với các hoạt động tạo ra giá trị. Trước đây, chỉ có các trung tâm chi phí² chức năng, chẳng hạn như IT, là nơi theo dõi các khoản chi tiêu và không thể làm rõ được những yếu tố gây ra phí tổn đó. Các bộ phận và các nhóm IT tham gia phát triển sản phẩm thường được coi là các trung tâm chi phí, những bộ phận có thể được quản lý và kiểm soát độc lập với doanh nghiệp. Tư duy truyền thống cho rằng tìm được các nguồn cung ứng dịch vụ IT rẻ hơn sẽ giúp giảm các chi phí mà vẫn đem lại kết quả tốt không kém. Nếu việc đó dễ dàng như vậy thì có lẽ bạn sẽ không cần đọc cuốn sách này. Trên thực tế, chính hoạt động kinh doanh là yếu tố dẫn đến chi phí phát triển sản phẩm và IT, vì vậy chúng ta không thể quản lý chúng một cách độc lập.

² Trung tâm chi phí: Là một bộ phận trong tổ chức không trực tiếp tạo ra lợi nhuận nhưng vẫn buộc tổ chức phải bỏ chi phí để vận hành. (BTV)

Kế toán (hoặc chi tiêu) dựa trên hoạt động cho phép chúng ta phân bổ toàn bộ chi phí dịch vụ và hoạt động cho hoạt động kinh doanh hoặc sản phẩm dẫn đến những khoản chi đó. Nó cung cấp cho chúng ta một bức tranh rõ nét hơn về giá trị tài chính thực mà sản phẩm mang lại. Tuy nhiên, giống như tất cả các mô hình và cách tiếp cận kinh doanh, phương pháp kế toán dựa trên hoạt động không phải là liều thuốc chữa bách bệnh. Chúng ta cần thận trọng, không theo đuổi sự chính xác không cần thiết, không tạo ra các mô hình và quy trình phức tạp hơn mức giá trị mà chúng ta định cung cấp. Mục đích đơn giản là để nhận được thông tin tốt hơn nhằm điều chỉnh các kế hoạch và hoạt động giúp cải thiện giá trị – bắt đầu với quy mô nhỏ và dừng lại khi chúng ta có đủ bằng chứng thực nghiệm để đưa ra quyết định.

ĐƯA RA CÁC QUYẾT ĐỊNH TỐT HƠN BẰNG PHƯƠNG PHÁP CHI TIÊU DỰA TRÊN HOẠT ĐỘNG

Câu chuyện của một cựu lãnh đạo doanh nghiệp dưới đây giúp chúng ta hiểu bằng cách nào mà phương pháp kế toán dựa trên hoạt động có thể làm rõ cách thức mà công nghệ hỗ trợ giá trị cho khách hàng:

Trong một nỗ lực nhằm cắt giảm chi phí, Ban Tài chính Kinh doanh của chúng tôi đã đưa ra các mục tiêu không thực tế cho năm tài khóa tiếp theo. Họ gặp khó khă voới những việc liên quan đến các hạng mục ngân sách đã xác định, ví dụ như chi phí cho các máy chủ, và không hiểu tại sao chúng tôi không thể cùng lúc vừa giảm mức biên chế vừa hỗ trợ được nhiều người và nhiều hệ thống. Để giúp họ hiểu tình hình liên quan, chúng tôi chuyển sang áp dụng nguyên tắc kế toán dựa trên hoạt động để phân bổ chi phí cho các hoạt động kinh doanh (việc vận hành, quản lý doanh thu, tiếp thị, quan hệ khách hàng, quản lý chuỗi cung ứng...) chứ không phải các hạng mục trong ngân sách (nhân viên IT, phần mềm, phần cứng, IPS, máy chủ...). Hệ thống quản lý tài chính của chúng tôi vốn không được thiết lập theo quan điểm này và có thời hạn chặt chẽ, vì vậy chúng tôi đã sử dụng tất cả những gì có trong tay: bảng tính, số lượng hoạt động hiện tại, hai người, hai ngày, tiếp cận toàn bộ ban quản lý IT cấp cao để lấy thông tin cùng với nhiều đồ ăn thức uống nữa.

Chúng tôi không tập trung để tính đúng hoặc chính xác 100%: chúng tôi xác định độ chính xác 90-95% là đủ. Mục tiêu là cung cấp cho các giám đốc điều hành bức tranh đầy đủ về cách thức mà các chi phí IT gắn liền với việc phục vụ khách hàng và sự phát triển của tổ chức.

Thật may mắn là chúng tôi am hiểu về các dịch vụ IT và chi phí liên quan đến hoạt động kinh doanh. Chúng tôi có thể gắn trực tiếp nhiều khoản chi phí với một sản phẩm hoặc dịch vụ kinh doanh. Ví dụ: trung tâm hỗ trợ khách hàng của chúng tôi nhận tất cả các chi phí liên quan đến phần mềm nhận diện giọng nói tương tác. Các chi phí khác, ví dụ như các dịch vụ email, phải được phân chia giữa các đơn vị kinh doanh, vì vậy chúng tôi tính số người của họ và chia những chi phí này theo tỷ lệ tương ứng. Chúng tôi cũng phân bổ các chi phí cụ thể cho bộ phận của mình, đó là những chi phí cho quản lý dịch vụ của bộ phận và các khoản tiêu thụ dịch vụ chung.

Kết quả của nỗ lực này là hàng loạt các bảng biểu thể hiện các hoạt động kinh doanh đã dẫn dắt chi phí IT như thế nào. Khi được nghe trình bày về các thông tin này, thay vì các hạng mục chi tiêu ngân sách truyền thống, các nhà điều hành thấy thoải mái hơn khi đưa ra quyết định hỗ trợ (hoặc không) hỗ trợ việc nào trong bản giải trình ngân sách của chúng tôi. Điều quan trọng nhất là mọi người có một bức tranh rõ ràng hơn về chi phí thực của việc sở hữu các sản phẩm, dịch vụ kinh doanh và chúng tôi có thể tính Chi phí Trì hoãn một cách thuận lợi hơn để quyết định rút lại hoặc thay thế các hệ thống.

TRÁNH SỬ DỤNG NGÂN SÁCH LÀM CƠ SỞ ĐỂ ĐÁNH GIÁ HIỆU NĂNG

Có lẽ sai lầm lớn nhất chúng ta có thể phạm phải liên quan đến ngân sách là sử dụng chúng làm một chỉ số chính về hiệu năng, từ đó khen thưởng và công nhận năng lực của một cá nhân, một nhóm hoặc toàn bộ tổ chức. Chi tiêu trong ngân sách được cấp chỉ cho thấy chúng ta có chi hoặc thu ở mức đã tuyên bố hay không. Nếu chúng ta nói với các nhóm rằng họ sẽ chi tiêu nhiều hơn hay ít hơn mức họ cần để thực hiện công việc của mình thì họ sẽ tìm ra cách làm đúng như vậy hoặc dành rất nhiều thời gian để giải trình tại sao họ không thể. Tuy nhiên, điều này ngăn chúng ta chú ý đến những câu hỏi quan trọng nhất: chúng ta có lên kế hoạch đúng cấp độ, có đặt ra các mục tiêu khả thi, có trở nên hiệu quả hơn, có cải thiện được sự hài lòng của khách hàng không? Các sản phẩm của chúng ta đang tốt lên hay kém đi? Chúng ta có đang trong tình trạng tài chính tốt hơn trước đây không?

Những phần thưởng được trao cho các kết quả tài chính thuần tốt sẽ hiệu quả hơn khi chúng được chia đều, không chỉ cho ban quản lý và điều hành cấp cao mà cho tất cả các nhân viên trong tổ chức. Các nhóm làm việc cuối cùng sẽ làm cho tổ chức tê liệt bởi sức ỳ và sự né tránh trách nhiệm khi những đóng góp của họ không được công nhận và việc tưởng thưởng dựa trên một quy trình được coi là không công bằng. Ngược lại, mọi người có xu hướng đi theo các nhà lãnh đạo giỏi và đóng góp để tổ chức lớn mạnh khi nỗ lực của mọi người đều được công nhận và khích lệ như nhau.

TÁC ĐỘNG TÍCH CỰC CỦA ĐỘNG CƠ TÀI CHÍNH: TRƯỜNG HỢP CỦA WESTJET

WestJet là một trong những hãng hàng không thành công nhất về tài chính ở Bắc Mỹ trong 15 năm qua. Những người sáng lập WestJet biết rằng, nếu muốn thành công, điều quan trọng là phải xây dựng được một nền văn hóa mang tính trách nhiệm và sở hữu cho tất cả nhân viên. Để làm được việc này, họ giải thích rõ ràng về chiến lược và mục đích của hãng, sàng lọc và huấn luyện nhân viên theo định hướng một nền văn hóa tốt và phù hợp với các giá trị đồng thời thiết lập các động cơ tài chính có lợi cho tất cả nhân viên.

Mỗi năm hai lần, một phần lợi nhuận của công ty được phân phối cho tất cả nhân viên theo tỷ lệ trên mức lương cơ bản của họ. Tất cả nhân viên được mời tham dự bữa tiệc chia sẻ lợi nhuận. Tại đó, các nhà quản lý trực tiếp đưa những tấm séc cho các thành viên trong nhóm, tốt nhất là trao tận tay để có thể đích thân biểu dương mọi nhân viên vì những đóng góp của họ.

Ngoài ra, WestJet còn cho phép nhân viên tự nguyện mua cổ phiếu của hãng lên đến 20% tổng thu nhập của họ. Năm 2012, có hơn 85% nhân viên tham gia vào chương trình này và trở thành chủ sở hữu một phần của WestJet.

Những động cơ tài chính này đã tạo nhận thức sâu sắc về trách nhiệm và quyền sở hữu cho tất cả nhân viên. Mọi người đều biết rằng những quyết định họ đưa ra trong công việc hằng ngày và cách họ đối xử với khách hàng sẽ tác động trực tiếp đến thu nhập của WestJet; cá nhân họ chính là người chia sẻ những niềm vui hay nỗi buồn có được từ những quyết định đó.

Phương pháp này đã giúp WestJet giữ vững vị thế trong ngành công nghiệp cạnh tranh khốc liệt này trong suốt gần hai thập kỷ. Cuối năm 2013, WestJet đã đưa ra báo cáo về lợi nhuận hằng năm trong 17 năm (trong số 18 năm hoạt động của hãng này).

CHẤM DỨT VIỆC ĐƯA RA CÁC QUYẾT ĐỊNH KINH DOANH DỰA TRÊN CHI TIÊU VỐN ĐẦU TƯ SO VỚI CHI PHÍ HOẠT ĐỘNG

Mối quan tâm về việc báo cáo so sánh Chi phí đầu tư (CapEx) với Chi phí hoạt động (OpEx) là điều rất quan trọng đối với các tổ chức. Mọi người rất chú ý đến việc này do sẽ nhận được những lợi ích về thuế và các tác động tài chính tích cực từ việc báo cáo các phí tổn của tổ chức theo hai loại này. Tiền đề cơ bản để vốn hóa các hệ thống phần mềm là xem chúng như một tài sản tạo ra lợi ích cho tổ chức trong tương lai. Điều này có thể tác động quan trọng đến bảng cân đối kế toán và sau đó đến giá trị thị trường của một tổ chức.

Thật không may là sự phân biệt này thường được dùng làm cơ sở để đưa ra các quyết định kinh doanh quan trọng. Nó tạo thêm một yếu tố phức tạp khác cho tiến trình ra quyết định và cấp vốn cho đổi mới. Tất cả các chi phí liên quan đến bất kỳ công việc nào cũng phải được phân thành một trong hai loại; quy trình quản lý truyền thống các loại này cho rằng một công việc của nhóm phải là loại này hoặc loại kia mà không thể là cả hai ở cùng một thời điểm.

Quy trình truyền thống cũng không làm rõ chi phí thực sự của quyền sở hữu và làm gia tăng chi phí hoạt động. Một dự án sẽ được cấp vốn đầy đủ, cho phép chúng ta dàn trải việc báo cáo về chi phí đó trong một khoảng thời gian dài, vì vậy nó sẽ ít có tác động ngắn hạn hơn đối với lợi nhuận. Tuy nhiên, nhiều hạng mục được cấp vốn trong dự án gốc có tác động tiêu cực lên OpEx, trước hoặc ngay sau khi dự án đổ bể. Các chi phí hoạt động dài hạn cần thiết để hỗ trợ tính phức tạp ngày càng tăng do các dự án gây ra đối với các hệ thống lại không được tính đến khi các dự án vốn hóa được phê duyệt (vì chúng không xuất phát từ cùng một loại). Việc tiếp tục hỗ trợ và ngừng phát triển sản phẩm và dịch vụ là một rắc rối của OpEx. Cuối cùng, các nhóm OpEx sẽ mắc kẹt với việc giải trình về chi phí tăng nhanh do sự phức tạp phát sinh từ các quyết định CapEx.

Nếu chúng ta nghiêm túc về sự đổi mới, thì việc cấp vốn từ loại nào không phải là vấn đề quan trọng. Những cuộc thảo luận cởi mở, thẳng thắn và dựa trên bằng chứng thực tế của tổng chi phí từ đầu đến cuối của sản phẩm là những gì mà chúng ta nên sử dụng làm cơ sở đưa ra các quyết định kinh doanh. Việc phân bổ quỹ phát triển một sản phẩm vào CapEx hay OpEx nên do các kế toán thực hiện sau khi đã đưa ra các quyết định kinh doanh.

Trước tiên chúng ta hãy xem xét miền khám phá. Hầu hết các ý tưởng đều mang lại giá trị bằng không hoặc giá trị âm. Do đó, cần coi tất cả các hoạt động khám phá là OpEx. Chúng ta vẫn cần các nhóm xác định số lượng nguồn lực mà họ định dùng để khám phá, nhưng không nên buộc họ phải được phê duyệt kinh phí mỗi khi họ muốn kiểm thử điều gì đó mới mẻ trong giới hạn quy định.

Chuyển sang miền khai thác, nhóm tài chính và sản phẩm cần thường xuyên liên hệ với nhau để xác định cách phân bổ nguồn tài chính. Chúng ta muốn tránh làm gia tăng tính phức tạp và lãng phí không cần thiết khi quyết định phương pháp theo dõi việc phân bổ CapEx so với OpEx. Phương pháp này phải đủ dễ để mọi người hiểu được nó hoạt động như thế nào và phải thể hiện chính xác tuyên bố giá trị dài hạn. Cuối cùng, việc tính chi phí vào CapEx có thể rất đơn giản, chỉ như việc xác định rằng một tỷ lệ phần trăm cố định về nguồn lực (hoặc thời gian) của nhóm này được chi cho việc phát triển những tài sản có thời hạn sử dụng đủ lâu để được cấp vốn. Dưới đây là một số chủ đề để thảo luận với cơ quan tài chính về các quyết định cấp vốn CapEx:

◆ Làm thế nào chúng ta có thể xây dựng một mô hình linh hoạt để phân bổ ngân sách dựa trên các nguyên tắc CapEx và OpEx nhưng lại tránh sử dụng các quy tắc và quy trình cứng nhắc đòi hỏi mọi người phải cạnh tranh để được cấp vốn tại cùng một thời điểm?

◆ Yếu tố nào, ngoài các chi phí dự án đã dự kiến, sẽ ảnh hưởng đến mức độ nghiêm túc và cẩn trọng của chúng ta khi đưa ra các quyết định cấp vốn: sự phức tạp, ước tính thời gian, quy mô nhóm, ảnh hưởng thực của chi phí hoạt động, hay điều gì khác?

◆ Làm thế nào chúng ta có thể quản lý các sáng kiến cục bộ so với các sáng kiến ở cấp độ doanh nghiệp nhằm giảm sự trì hoãn và tổng thời lượng phản hồi cho các cơ hội cục bộ?

◆ Làm thế nào mà chúng ta có thể kết cấu các quyết định tài chính để phù hợp với các khung thời gian ngắn hơn và cải thiện tính khả dụng cho nhiều nhóm hơn?

◆ Làm thế nào để chúng ta có thể đưa ra quyết định cấp vốn dựa vào việc phân phối đã được khẳng định là đang đem đến các sản phẩm hiệu quả cao chứ không dựa vào số lượng hoạt động?

Trong các cuộc thảo luận này, điều quan trọng là phải xem xét thời gian sử dụng dự kiến của sản phẩm. Về mặt kỹ thuật, các tài sản phần mềm chỉ nên được vốn hóa nếu thời gian sử dụng dự kiến của sản phẩm đáp ứng hoặc vượt quá thời gian khấu hao hiện tại đối với các sản phẩm phần mềm – nhiều doanh nghiệp hiện tính thời gian khấu hao là ba năm. Tuy nhiên, có vẻ không thực tế khi cho rằng tất cả các hệ thống này đều có thời gian sử dụng là ba năm nếu nó không thay đổi. Điều này đưa đến một câu hỏi thú vị: đâu là việc ít rủi ro và nhiều trách nhiệm hơn:

◆ Phân loại việc phát triển sản phẩm phần mềm hoàn toàn trong OpEx, hoặc

◆ Vốn hóa các chi phí và sau đó đề xuất giảm nếu sản phẩm bị rút khỏi hệ thống trước khi khấu hao hoàn toàn?

Có lẽ không có một câu trả lời dứt khoát nào cả; bạn cần phải xem xét nhiều biến số vốn rất khác nhau trong mỗi tổ chức.

ĐIỀU CHỈNH CÁC QUY TRÌNH ĐẤU THẦU IT ĐỂ TĂNG CƯỜNG KIỂM SOÁT VIỆC PHÂN PHỐI GIÁ TRỊ

Trong cuốn Vượt qua khủng hoảng (Out of the Crisis³) xuất bản năm 1982, W. Edwards Deming đề xuất 14 nguyên tắc quản trị cần thiết để nâng cao hiệu quả hoạt động kinh doanh cho các công ty Mỹ. Nguyên tắc số 4 là thế này: “Hãy ngừng ngay việc quyết định làm ăn dựa trên nhãn giá của sản phẩm. Thay vào đó, hãy giảm thiểu tổng chi phí. Tìm một nhà cung cấp duy nhất cho bất kỳ mặt hàng nào dựa trên mối quan hệ trung thành, tin tưởng và dài lâu.”

³ Được Alpha Books mua bản quyền và xuất bản năm 2012.

Hơn 30 năm sau, chúng ta chứng kiến vẫn còn nhiều tổ chức chưa hiểu được ý nghĩa thực sự của nguyên tắc này. Chúng ta không định lượng được tổng chi phí, chúng ta coi các sản phẩm và dịch vụ là hàng hóa có thể thay thế và có thể dễ dàng được sản xuất bởi bất kỳ nhà cung cấp nào. Mặc dù các quy trình mua sắm được sử dụng để quyết định các hợp đồng có thể đưa đến các mối quan hệ lâu dài, nhưng chúng ít khi được xây dựng trên sự phối hợp và niềm tin. Kết quả tất yếu là các chính sách, quy trình và hoạt động mua sắm ngăn cản chúng ta cải thiện giá trị mà chúng ta cung cấp thông qua phân phối phần mềm.

Sai lầm đầu tiên chúng ta phạm phải là nghĩ rằng với một lượng lớn kế hoạch được lập trước, chúng ta có thể quản lý rủi ro khi nhận được sản phẩm gì đó không mang lại giá trị như kỳ vọng. Ở nhiều doanh nghiệp lớn, khi người quản lý thu hút bất kỳ bên thứ ba nào vào các dịch vụ phân phối phần mềm thì phải đánh giá trước tất cả các kết quả mong muốn trong thông báo về đề nghị mời thầu. Sau đó, các nhà cung cấp sẽ có phản hồi chi tiết cách mà họ sẽ phân phối đúng sản phẩm mong muốn và mức giá của nó, thường dựa trên mức giá và chi phí theo giờ cộng với lãi suất mong muốn. Các quyết định trao thầu được đưa ra trên cơ sở những phản hồi nhận được và phần thuyết trình của các nhóm trong danh sách chung cuộc.

Quy trình thầu hết sức chi tiết và đầy khó khăn này có một số tác động phụ tiêu cực như sau:

Đây là biện pháp kém hiệu quả trong quản lý rủi ro về phát triển sản phẩm Nó dựa trên quan niệm sai lầm rằng chúng ta có thể biết trước và biết chính xác những gì chúng ta cần – nói cách khác là chúng ta cho rằng trong khi xây dựng hệ thống, chúng ta sẽ không có bất kỳ khám phá quan trọng nào về những gì mà người dùng thấy có giá trị hoặc chúng ta sẽ không gặp phải bất kỳ sự phức tạp ngoài dự kiến nào.

Nó ưu tiên các nhà cung cấp hiện tại

Các nhà cung cấp đã hiện diện trong tổ chức có thể tiếp cận nhân viên của tổ chức một cách dễ dàng hơn nên có thể hiểu rõ hơn về ngân sách và mục tiêu cần phải đáp ứng. Do quy trình mua sắm áp dụng cho các nhà cung cấp mới rất khó khăn, nên sẽ tiện hơn nếu tự động gia hạn hợp đồng đã có, kể cả với các nhà cung cấp không tốt lắm. Chi phí và rủi ro gắn với việc tìm một nhà cung cấp mới thường được cho là lớn hơn việc gia hạn hợp đồng hiện tại.

Nó ưu tiên các nhà cung cấp dịch vụ lớn

Các công ty lớn thuê nhân viên chuyên trả lời những đề nghị mời thầu bằng những chi tiết vụn vặt và phương án tùy chọn nhưng có ít hoặc không có tác động liên quan.

Nó hạn chế tính minh bạch

Chúng ta thường khen thưởng thành công cho chi phí phân phối mà ít để ý đến chi phí tích hợp, chi phí thay đổi tiến trình kinh doanh hoặc chi phí hoạt động hiện thời. Chúng ta ít khi đánh giá xem sản phẩm được cung cấp sẽ tác động đến việc phân phối giá trị từ đầu đến cuối như thế nào. Ví dụ, việc phân phối sản phẩm ở ngoài nước có vẻ không tốn kém xét về chi phí cho từng đơn vị sản phẩm. Tuy nhiên, khi tính đến chi phí truyền thông và di chuyển gia tăng, cũng như sự chậm trễ trong phản hồi và khối lượng công việc phải làm lại do khác múi giờ, thì việc đó có thể mất nhiều thời gian hơn so với việc đồng phân phối – với mức chi phí tương tự.

Nó không chính xác

Do sai lầm của công tác kế hoạch (xem Chương 2), cả nhà cung cấp và nhà quản lý đều có xu hướng lạc quan quá mức khi dự đoán số lượng người và khối lượng công việc cần thiết vì họ biết rằng giá cả hợp đồng là yếu tố quan trọng nhất tác động đến việc ra quyết định. Các nhà cung cấp biết họ có thể kiếm tiền bù lại bằng các yêu cầu thay đổi.

Nó xem nhẹ kết quả

Hiệu năng của hợp đồng được đánh giá bằng khả năng cung cấp dịch vụ theo hợp đồng, theo đơn giá đã ký kết và trong khoảng thời gian đã thỏa thuận. Thông thường, không ai đề cập đến việc các dịch vụ được cung cấp phải hoạt động tốt như thế nào. Không cần biết kết quả ra sao nhưng các nhà cung cấp thường được trao thưởng bằng cách được phép nhận các hợp đồng khác để hỗ trợ, sửa chữa và cải tiến dịch vụ.

BÍ QUYẾT

Nếu bạn tuân thủ chặt chẽ một hợp đồng dài hạn dựa trên dự án với mục tiêu cụ thể là phân phối giải pháp ở cuối kỳ hạn thì hãy giảm thiểu rủi ro bằng cách đề nghị thanh toán trước cho nhà cung cấp, dựa trên việc cung cấp phần mềm hoạt động⁴ tăng dần. Điều này khuyến khích họ cung cấp cho bạn phần mềm hoạt động có thể đưa vào sản xuất để bạn có thể nhận được phản hồi từ khách hàng về giá trị của giải pháp. Sau đó, bạn có thể điều chỉnh hướng phát triển của sản phẩm dựa trên các kết quả kiểm thử của bạn.

4 Working software là phần mềm với những chi tiết đã được tích hợp, kiểm thử và sẵn sàng cung cấp cho khách hàng hoặc triển khai vào quá trình sản xuất. (ND)

Sai lầm thứ hai trong quy trình mua sắm thông thường là cho rằng chất lượng của đội ngũ làm công tác phân phối và phần mềm được phân phối của tất cả các dịch vụ đều giống nhau. Qua nhiều trải nghiệm tồi tệ, nhiều người trong chúng ta biết điều đó không đúng. Có rất nhiều yếu tố quyết định mức độ thành công của việc tuyển chọn nhà cung cấp, ít nhất cũng biết được việc đó tốn kém bao nhiêu. Tỷ lệ sự cố lỗi và khắc phục lỗi là bao nhiêu? Nỗ lực duy trì gắn với các giải pháp của họ là gì? Giải pháp đó có bao nhiêu dòng mã (càng ít càng tốt)? Chúng ta có thể làm việc với họ gần gũi đến mức nào? Chúng ta có thể tin tưởng họ không? Mặc dù chúng ta có thể có những hiểu biết sâu sắc khi nói chuyện với các khách hàng khác về nhà cung cấp, nhưng vẫn phải kiểm tra chặt chẽ. Chúng ta cần kiểm tra mối quan hệ đó và đánh giá kết quả, việc đòi hỏi phải điều chỉnh các quy trình tuyển chọn các nhà cung cấp dịch vụ bên thứ ba.

CHÍNH PHỦ ANH THAY ĐỔI QUY TRÌNH MUA SẮM IT THEO HƯỚNG KHUYẾN KHÍCH ĐỔI MỚI

Đầu năm 2014, Chính phủ Anh công bố những thay đổi đáng kể về các quy định trong giao thầu và quản lý các hợp đồng dịch vụ IT. Những thay đổi này nhằm khuyến khích cạnh tranh trong lĩnh vực dịch vụ IT và giúp chính phủ trở thành một khách hàng thông minh hơn của các nhà cung cấp dịch vụ. Họ tin rằng sẽ có các dịch vụ IT tốt hơn bằng cách hạn chế các hợp đồng IT lớn và mở rộng các nguồn cung cấp tiềm năng.

Để dễ dàng hơn cho các doanh nghiệp vừa và nhỏ tham gia đấu thầu các hợp đồng IT của chính phủ, chính phủ Anh công bố bốn thay đổi lớn trong quy trình mua sắm dịch vụ IT của Chính phủ như sau:

• Không chấp nhận hợp đồng nào trị giá trên 100 triệu bảng, trừ trường hợp ngoại lệ.

• Các công ty có hợp đồng cung cấp dịch vụ sẽ không được phép cung cấp tích hợp hệ thống trong cùng một cơ quan của Chính phủ.

• Các hợp đồng mới sẽ chỉ kéo dài tối đa là 2 năm.

• Không hợp đồng nào được phép tự động gia hạn.

Chính phủ Anh hy vọng sẽ tạo ra nhiều dịch vụ hiệu quả hơn và đáp ứng tốt các yêu cầu của công chúng bằng cách tăng khả năng tiếp cận các giải pháp kỹ thuật số mang tính đổi mới và tiết kiệm chi phí. Họ mở rộng số lượng các nhà cung cấp và tạo nhiều cơ hội hơn để đánh giá, đàm phán lại những hợp đồng có thể dựa trên các công nghệ lỗi thời đắt đỏ hoặc đơn giản là không mang lại giá trị.

Tuyên ngôn linh hoạt⁵ (agile manifesto) khuyến nghị chúng ta ưu tiên phối hợp với khách hàng hơn là đàm phán hợp đồng. Chúng ta cần liên tục làm việc với các nhà cung cấp để tạo ra các sản phẩm chất lượng cao. Chúng ta sẽ có được các mối quan hệ và kết quả tốt nhất khi không phớt lờ các yêu cầu và ngồi chờ để nhận được một sản phẩm hoặc dịch vụ tuyệt vời vài tháng sau đó. Chúng ta phải can dự, quản lý các hợp đồng và các mối quan hệ, khuyến khích tính linh hoạt và tìm kiếm các cơ hội kiểm thử với các nhà cung cấp khác nhau để có thể đánh giá năng lực cung cấp giá trị của họ.

⁵ Tuyên ngôn linh hoạt (agile manifesto): Còn gọi là Tuyên ngôn Phát triển Phần mềm Linh hoạt, là một tuyên ngôn chính thức gồm 4 giá trị chính và 12 nguyên tắc hướng dẫn thực hiện cách tiếp cận tập trung vào con người trong phát triển phần mềm. (BTV)

KẾT LUẬN

Những tổ chức nào tiếp tục gắn việc hình thành các quyết định cấp vốn với chu kỳ tài chính sẽ phải đối mặt với những trở ngại nghiêm trọng trong cải thiện năng lực đổi mới của họ. Chúng ta cần vượt ra khỏi kết cấu ngân sách tập trung và tạo được mạch xuyên suốt trong các quy trình dự báo, lập kế hoạch và báo cáo tài chính. Đây là việc quan trọng nếu chúng ta muốn nhận được nhiều lợi nhuận hơn ngoài những lợi ích gia tăng từ việc áp dụng các nguyên tắc tinh gọn.

Chúng ta nên phân tách các quyết định cấp vốn khỏi chu kỳ ngân sách thường niên và đừng quan tâm đến việc đó là chi tiêu vốn hay chi phí hoạt động. Điều này giúp chúng ta đưa ra những quyết định tốt hơn về việc nào và khi nào cần cấp vốn để đạt được những kết quả mong muốn. Chúng ta vẫn cần quản lý một cách cẩn thận các khoản chi tiêu, nhưng những kết quả tốt hơn có thể đạt được thông qua các chu kỳ lập kế hoạch, dự báo và giám sát ngắn hơn cùng với các chi phí liên quan được đưa trở lại các hoạt động kinh doanh. Hạn chế các nguồn lực và khung thời gian để kiểm thử các ý tưởng giúp chúng ta dễ dàng giảm các khoản đầu tư vào các ý tưởng không hiệu quả. Sau đó các nguồn lực có thể được dùng vào việc khám phá các ý tưởng sản phẩm và dịch vụ mới.

Cuối cùng, để hỗ trợ đổi mới và thực nghiệm, chúng ta cần điều chỉnh các quy trình và quy tắc mua sắm. Nếu không có mối quan hệ tin cậy lâu dài dựa trên mong muốn cung cấp giá trị tốt hơn của cả hai phía thì các tổ chức lớn sẽ mãi bị cản trở bởi các hệ thống kế thừa và các sản phẩm lỗi thời ngay cả trước khi chúng được triển khai.

Câu hỏi dành cho độc giả:

◆ Các nhóm sản phẩm của bạn có thể công khai thử nghiệm những ý tưởng và công nghệ mới mà không tốn nhiều thời gian để xin chấp thuận và xin kinh phí không? Bạn có thể dễ dàng được cấp quỹ cho công việc mới liên quan đến công nghệ vào bất kỳ thời điểm nào trong năm, hay sẽ bị giới hạn trong một chu kỳ thường niên?

◆ Các tiêu chí của bạn về một khoản đầu tư thành công là gì? Có phải chỉ cần các dự án đạt tiến độ thời gian và trong ngân sách được cấp là đủ không, hay bạn phải nỗ lực đánh giá kết quả về khách hàng và tổ chức?

◆ Bạn dành bao nhiêu thời gian mỗi năm cho việc quản lý ngân sách của nhóm, trong đó có việc chuẩn bị các báo cáo và giải trình cho những sai biệt?

◆ Bạn được đề nghị lập kế hoạch chi tiêu cụ thể đến mức nào và thường xuyên như thế nào? Có quy trình dễ dàng nào cho việc điều chỉnh và báo cáo liên tục trong kế hoạch đó không?

◆ Quy trình phân bổ chi tiêu vốn so với chi phí hoạt động có ngăn cản mọi người trong tổ chức đưa ra các quyết định đầu tư có trách nhiệm không? Nếu câu trả lời là có, thì có cách nào đơn giản và ít rủi ro để thực nghiệm một cách tiếp cận khác không?

Chương 14Biến IT thành một lợi thế cạnh tranh

Kết cấu trung tâm chi phí khỏa lấp khoảng trống năng lực của chúng ta trong việc xác định, mô hình hóa và đánh giá các giá trị mà nhiều người lao động tạo ra cho tổ chức của họ.

− KEN H. JUDY

Các bộ phận IT của doanh nghiệp phải đối mặt với các thế lực cạnh tranh mạnh mẽ. Ưu tiên hàng đầu của họ là duy trì hoạt động của các hệ thống kinh doanh quan trọng hiện tại, ngay cả khi chúng đã tồn tại quá lâu và phát sinh tính phức tạp. Bên cạnh đó, họ cũng phải chịu áp lực gia tăng tốc độ phân phối các sản phẩm và tính năng mới. Cuối cùng, do thường được coi là một trung tâm chi phí, nên các bộ phận IT luôn phải chịu áp lực gia tăng tính hiệu quả (thường biểu hiện bằng việc cắt giảm chi phí).

Những mục đích có vẻ xung đột với nhau này thường dẫn đến vòng xoáy tụt hậu. Việc giảm tính phức tạp và thay thế các hệ thống kế thừa bao giờ cũng cần đầu tư. Tuy nhiên, các khoản đầu tư thường đến dưới dạng các dự án lớn, kéo dài trong nhiều năm và thường bị từ bỏ hoặc triển khai dở dang do chi phí tăng vùn vụt và/hoặc do những thay đổi nhân sự ở cấp điều hành. Sự gia tăng tính phức tạp cùng với nhu cầu nâng cao hiệu quả hơn nữa sẽ làm giảm khả năng của IT trong quản lý hiệu quả những công việc đã được hoạch định. Yêu cầu về sự thay đổi gia tăng, cộng với môi trường IT mong manh, dẫn đến phát sinh nhiều công việc ngoài kế hoạch và càng làm giảm khả năng IT.

Trong chương này, chúng ta thảo luận về một số chiến lược nhằm tăng cường khả năng thích ứng của IT trước nhu cầu kinh doanh đầy biến động, cải thiện tính ổn định của các dịch vụ IT và giảm tính phức tạp các hệ thống và hạ tầng IT của chúng ta. Nhiều trong số các chiến lược này khởi phát từ phong trào Phát triển và Vận hành (DevOps), mục đích là giúp chúng ta làm việc an toàn với quy mô phù hợp trong một môi trường sôi động và có tầm quan trọng cao.

ĐỊNH HƯỚNG LẠI TƯ DUY IT

Trước đây, IT được xem là một trung tâm chi phí và là một nhân tố bên trong có giá trị thúc đẩy kinh doanh, chứ không phải nhân tố tạo lợi thế cạnh tranh. Trong nhiều năm, Nicholas Carr từng mỉa mai, quan điểm chính thống cho rằng “IT chẳng có gì quan trọng cả”. Ngay cả một số người theo thuyết tinh gọn đôi khi cũng chỉ coi IT là “một bộ phận”. Điều này đã tạo ra những gì mà Marty Cagan, tác giả cuốn Inspired: How to create products customers love, gọi là “tư duy IT”, trong đó IT đơn giản chỉ là một nhà cung cấp dịch vụ cho “hoạt động kinh doanh”.

"Nhà cung cấp phát triển phần mềm của bạn có mức độ ảnh hưởng như thế nào khi đi đến quyết định dịch vụ hoặc sản phẩm kinh doanh bạn phân phối?"

Hình 14-1: Các lãnh đạo doanh nghiệp nghĩ gì về mối quan hệ giữa hoạt động kinh tế và IT

Vấn đề này càng trở nên trầm trọng hơn khi áp dụng mô hình dự án truyền thống để cấp vốn và quản lý các dự án IT. Công việc được tạo ra trong các dự án IT thường được chuyển giao (hoặc bỏ mặc) cho các bộ phận vận hành IT thực hiện nên những người quản lý các dự án có rất ít động lực để nghĩ đến những hậu quả dài hạn từ các quyết định thiết kế của họ, nhưng lại có động cơ mạnh mẽ để đưa vào càng nhiều tính năng càng tốt trong một khung biểu thời gian eo hẹp. Điều này dẫn đến một phần mềm khó khăn trong vận hành, thay đổi, triển khai, bảo trì và giám sát và làm tăng tính phức tạp của môi trường vận hành, khiến các dự án tiếp theo khó được triển khai. Charles Betz, tác giả cuốn Architecture and Patterns for IT Service Management, Resource Planning and Governance: Making Shoes for the Cobbler’s Children (tạm dịch: Kiến trúc và kết cấu quản lý dịch vụ, lập kế hoạch nguồn lực và quản trị thông tin: Sản xuất giày cho những đứa trẻ nhà Cobbler), nhận xét:

Do đây là lĩnh vực hoạt động IT được hiểu rõ nhất nên giai đoạn dự án thường được tối ưu hóa, gây ảnh hưởng bất lợi cho các lĩnh vực khác trong tiến trình, và vì vậy gây thiệt cho toàn bộ chuỗi giá trị. Thách thức trong quản lý dự án IT nằm ở chỗ, các mục tiêu chuỗi giá trị rộng hơn thường bị đánh giá là “không trong phạm vi” đối với một dự án cụ thể và các dự án không phải chịu trách nhiệm giải trình về việc góp phần dẫn đến sự lộn xộn của tổng thể hệ thống.

Bộ phận vận hành IT – một phần của phòng IT và có lẽ là trung tâm chi phí cuối cùng – phải gánh chịu hậu quả của những quyết định được đưa ra mỗi ngày như thế. Đặc biệt, các hệ thống tích hợp mà họ phải duy trì hoạt động vốn dĩ cực kỳ phức tạp và khó chịu, được xây dựng qua nhiều năm, và thường dễ đổ vỡ, vì vậy, họ có xu hướng tránh thay đổi chúng. Do luôn coi sự ổn định là ưu tiên hàng đầu, nên bộ phận vận hành IT nổi tiếng là bộ phận luôn nói “không” – một phản ứng hoàn toàn lý tính khi phải đối mặt với các rắc rối.

Các bộ phận vận hành IT sử dụng hai cơ chế chính để ngăn chặn dòng thác thay đổi: quy trình quản lý thay đổi và cơ chế tiêu chuẩn hóa. Quy trình quản lý thay đổi được sử dụng để giảm thiểu rủi ro do những thay đổi gây ra cho môi trường sản xuất và để đáp ứng các quy định đặt ra; mọi sự thay đổi trong hoạt động sản xuất thường phải được một nhóm (được gọi là Ban Cố vấn Thay đổi theo thuật ngữ của ITIL) xem xét trước khi được triển khai. Còn cơ chế tiêu chuẩn hóa được sử dụng để quản lý tính đa dạng của các môi trường vận hành, giảm chi phí và ngăn ngừa các vi phạm bảo mật; nó cũng đòi hỏi tất cả các phần mềm được sử dụng trong sản xuất (và thường cũng ở trong môi trường phát triển) phải được phê duyệt trước khi đưa vào sử dụng.

Hệ quả của các cơ chế này là tốc độ thay đổi trong các môi trường vận hành chậm lại rất nhiều và các nhóm không thể sử dụng các công cụ mà họ lựa chọn. Trong một số trường hợp nhất định, sự đánh đổi này có thể chấp nhận được nếu những quy định này thực sự có thể giúp cải thiện tính ổn định của các môi trường vận hành. Tuy nhiên, các dữ liệu thống kê lại không cho thấy điều đó. Trên thực tế, nhiều giả định nhấn mạnh rằng hoạt động của các bộ phận IT và mối quan hệ của bộ phận này với các bộ phận khác của tổ chức không còn hiệu quả nữa.

Theo Báo cáo Tình hình Phát triển và Vận hành 2014, hơn 9.000 người trên toàn thế giới đã được thăm dò ý kiến rằng theo họ thì điều gì tạo nên các tổ chức có hiệu năng cao, liệu IT có thực sự quan trọng đối với doanh nghiệp và những yếu tố nào ảnh hưởng đến hiệu năng của các bộ phận IT. Kết quả quan trọng đầu tiên mà cuộc khảo sát đem lại là một phương pháp thống kê hiệu quả để đánh giá hiệu năng IT. Các tổ chức IT hiệu năng cao có thể đạt được cả năng suất cao (được đánh giá bằng thay đổi về thời gian sản xuất và tần suất triển khai) và độ ổn định cao (được đánh giá bằng thời gian khôi phục dịch vụ sau khi xảy ra một sự cố làm giảm chất lượng dịch vụ). Các tổ chức IT hiệu năng cao cũng có tỷ lệ thay đổi thất bại thấp hơn 50% so với các tổ chức IT hiệu năng trung bình và thấp.

Các dữ liệu cho thấy những tổ chức có bộ phận IT hiệu năng cao có thể đạt năng suất và sự ổn định cao hơn. Hơn nữa, những doanh nghiệp có bộ phận IT hiệu năng cao cũng có khả năng đạt lợi nhuận, thị phần và các mục đích sản xuất cao gấp 2 lần so với những doanh nghiệp có bộ phận IT hiệu năng thấp.

Các biện pháp kỹ thuật liên quan nhiều nhất đến hiệu năng IT cao (tăng cả về năng suất và sự ổn định) là:

◆ Giữ cho cấu hình hệ thống, cấu hình ứng dụng và mã ứng dụng ở trạng thái kiểm soát phiên bản

◆ Đăng nhập và giám sát các hệ thống cảnh báo thất bại

◆ Các lập trình viên chia các tính năng lớn thành những thay đổi nhỏ, tăng dần mà sau đó được hợp nhất vào trục chính trên cơ sở thường nhật (như đã thảo luận trong Chương 8)

◆ Các lập trình viên và bộ phận vận hành thường xuyên đạt được kết quả hai bên cùng có lợi khi tương tác với nhau.

Còn có hai yếu tố khác giúp dự đoán chính xác hiệu năng IT cao. Thứ nhất là một nền văn hóa tổ chức có tính tin cậy cao như được trình bày trong Chương 1. Thứ hai là một quy trình phê duyệt thay đổi trên cơ sở đồng cấp. Nhiều tổ chức thành lập một nhóm độc lập có nhiệm vụ phê duyệt những thay đổi trong sản xuất. Tuy nhiên, các dữ liệu cho thấy mặc dù các quy trình bên ngoài như vậy làm giảm đáng kể năng suất nhưng lại có rất ít những tác động tích cực đến sự ổn định. Các cơ chế phê duyệt thay đổi đồng cấp (như lập trình cặp hoặc việc đánh giá mã của các lập trình viên khác) cũng có hiệu quả không thua kém các Ban Cố vấn Thay đổi trong việc tạo ra các hệ thống ổn định nhưng lại tạo ra năng suất tốt hơn đáng kể.

Mặc dù ủng hộ những biện pháp hiện tại của các công ty hiệu năng cao như Amazon và Google, nhưng các dữ liệu này mâu thuẫn trực tiếp với quan điểm cho rằng phân chia nhiệm vụ là cách quản lý rủi ro hiệu quả. Tuy nhiên, công trình nghiên cứu của Westrum về văn hóa an toàn cho thấy không có quy trình hoặc phương pháp kiểm soát nào có thể bù đắp được cho một môi trường mà con người không quan tâm đến kết quả khách hàng và tổ chức. Thay vì đưa ra các biện pháp kiểm soát để bù đắp cho các nền văn hóa ốm yếu, giải pháp là phải xây dựng một nền văn hóa mà mọi người chịu trách nhiệm về những kết quả do hành động của mình gây ra, đặc biệt là kết quả khách hàng.

Dưới đây là một liệu pháp đơn giản nhưng đem lại hiệu quả sâu rộng trong thúc đẩy những hành vi này:

Bạn xây dựng, bạn vận hành. Các nhóm xây dựng sản phẩm và dịch vụ mới phải chịu trách nhiệm vận hành và hỗ trợ các dịch vụ đó, ít nhất cho đến khi chúng hoạt động ổn định và có thể dự đoán chi phí hoạt động và hỗ trợ. Làm như vậy cũng giúp chúng ta đảm bảo có thể dễ dàng đánh giá chi phí vận hành dịch vụ và giá trị mà nó đem lại.

Biến trung tâm IT thành một tổ chức phát triển sản phẩm. Vòng đời và chiến lược phát triển sản phẩm được trình bày trong cuốn sách này nên được sử dụng để cung cấp các sản phẩm và dịch vụ nội bộ cũng như những sản phẩm, dịch vụ tiếp cận trực diện khách hàng.

Đầu tư vào việc giảm tính phức tạp của các hệ thống hiện hành. Sử dụng khả năng có được ở bước 1 để đầu tư vào công tác cải tiến đang được tiến hành nhằm mục đích giảm chi phí và rủi ro khi thay đổi các dịch vụ hiện hành.

TỰ DO VÀ TRÁCH NHIỆM

Để giảm gánh nặng hoạt động vận hành IT, điều quan trọng là chúng ta phải chuyển việc hỗ trợ các sản phẩm, dịch vụ và tính năng mới cho các nhóm xây dựng chúng. Để làm được điều này, chúng ta cần phải trao cho họ quyền tự chủ trong phát hành và vận hành các sản phẩm và tính năng mới cũng như trách nhiệm hỗ trợ chúng.

Ở Google, các nhóm nghiên cứu sản phẩm mới phải vượt qua một “vòng đánh giá trạng thái sẵn sàng vận hành” trước khi có thể phát hành bất kỳ dịch vụ nào. Sau đó, nhóm sản phẩm này có trách nhiệm đối với dịch vụ của mình trong giai đoạn đầu đi vào hoạt động (tương tự ý tưởng hỗ trợ giai đoạn đầu của ITIL). Sau một vài tháng, khi dịch vụ đã ổn định, nhóm sản phẩm có thể yêu cầu bộ phận vận hành – được gọi là Nhóm Kỹ thuật ổn định website của (Google’s Site Reliability Engineers – SRE) – tiếp quản việc vận hành dịch vụ hằng ngày, nhưng phải sau khi đã trải qua “vòng đánh giá trạng thái sẵn sàng bàn giao” để đảm bảo hệ thống đã sẵn sàng để bàn giao. Nếu dịch vụ gặp vấn đề nghiêm trọng sau khi được bàn giao, trách nhiệm hỗ trợ sẽ được chuyển lại cho nhóm sản phẩm cho đến khi họ có thể vượt qua một vòng đánh giá trạng thái sẵn sàng bàn giao khác.

Như đã thảo luận trong Chương 12, mô hình này đòi hỏi các nhóm sản phẩm phải làm việc với các bộ phận khác của tổ chức, bao gồm các bộ phận chịu trách nhiệm về tuân thủ, an ninh thông tin và vận hành IT trong suốt tiến trình phát triển. Cụ thể, các bộ phận IT tập trung hóa có trách nhiệm:

Cung cấp các tài liệu rõ ràng và cập nhật về các quy trình và phê duyệt cần thiết để cho phép các dịch vụ mới đi vào hoạt động và cách mà các nhóm có thể tiếp cận các tài liệu này.

Giám sát thời lượng sản xuất và các thỏa thuận cấp dịch vụ (SLA) khác đối với các dịch vụ này, chẳng hạn việc phê duyệt các gói phần mềm, cung cấp cơ sở hạ tầng (như môi trường kiểm thử) và không ngừng nỗ lực làm giảm những yếu tố này.

Đối với các dịch vụ được chấp thuận và đang được phát triển tích cực, các lập trình viên chia sẻ trách nhiệm với nhóm vận hành trong việc:

◆ Phản hồi với những yêu cầu ngừng hoạt động

◆ Thiết kế và phát triển các hệ thống giám sát, cảnh báo và những thông số mà chúng dựa vào

◆ Tạo cấu hình ứng dụng

◆ Thiết kế và đánh giá kiến trúc

Các kỹ sư xây dựng các tính năng mới cần có khả năng tự thúc đẩy việc thay đổi mã trực tiếp sau vòng đánh giá đồng cấp, ngoại trừ trong trường hợp những thay đổi có độ rủi ro cao. Tuy nhiên, họ phải luôn có mặt khi những thay đổi của họ đi vào vận hành để có thể hỗ trợ chúng. Nhiều thay đổi mã mới (đặc biệt những thay đổi có độ rủi ro cao) nên được “ra mắt tối” (dark launching − như được trình bày trong Chương 8) và hoặc là được bỏ qua trong quá trình sản xuất hoặc được đưa thành một phần của kiểm thử A/B.

Một số người mô tả mô hình này là “không vận hành” (no-ops¹) vì (nếu thành công), chúng ta sẽ giảm được đáng kể số lượng công việc hỗ trợ phản hồi mà nhân viên vận hành phải thực hiện. Trên thực tế, các nhóm vận hành tất cả các dịch vụ trong đám mây công cộng có thể sử dụng mô hình này để đi đến kết luận lô-gic về việc ở điểm nào thì các nhóm sản phẩm đã hoàn toàn kiểm soát – và chịu trách nhiệm – đối với việc xây dựng, triển khai và vận hành các dịch vụ trong toàn bộ vòng đời của chúng (Netflix là tổ chức tiên phong trong việc áp dụng mô hình này). Điều này dẫn đến sự kháng cự mạnh mẽ từ những người trong bộ phận vận hành vì lo sợ mất việc làm. Việc gán nhãn “không vận hành” rõ ràng là có tính khiêu khích và có vấn đề; trong mô hình mà chúng tôi miêu tả, yêu cầu về các kỹ năng vận hành thực ra lại gia tăng bởi vì các nhóm phân phối phải chịu trách nhiệm vận hành các dịch vụ của riêng họ. Nhiều nhân viên IT sẽ chuyển sang các nhóm xây dựng, phát triển, vận hành và hỗ trợ các sản phẩm và dịch vụ của tổ chức. Sự thực là những người làm trong bộ phận vận hành truyền thống sẽ phải trải qua giai đoạn học tập chuyên sâu và trải qua những thay đổi văn hóa để có thể thành công trong mô hình này. Tuy nhiên, điều này cũng đúng với tất cả các vị trí trong các tổ chức có khả năng thích ứng.

¹ NoOps – No Operations – là khái niệm về việc một môi trường IT có thể trở nên tự động và được tách khỏi hạ tầng cơ sở đến mức không cần phải có một nhóm chuyên quản lý phần mềm tại chỗ nữa. (ND)

Cần phải hiểu và thừa nhận rằng điều đó rất đáng sợ đối với nhiều người. Vì vậy, cần cung cấp các khóa huấn luyện và hỗ trợ cho những người muốn có sự chuyển đổi. Phải chứng tỏ được rằng mô hình chúng ta đưa ra không nhằm làm cho mọi người trở nên thừa thãi, nhưng họ phải sẵn sàng học hỏi và thay đổi (xem Chương 11). Cần đưa ra các gói trợ cấp thôi việc hào phóng cho những ai không hào hứng học hỏi các kỹ năng mới hay đảm nhận các vai trò mới trong tổ chức.

Loại bỏ gánh nặng của việc tạo dựng và hỗ trợ các sản phẩm và dịch vụ mới sẽ giải phóng sức ép cho các tổ chức IT trung tâm để họ có thể tập trung vào việc vận hành và phát triển các dịch vụ hiện tại và xây dựng các công cụ và nền tảng để hỗ trợ các nhóm sản phẩm.

XÂY DỰNG VÀ PHÁT TRIỂN NỀN TẢNG

Vai trò quan trọng nhất của IT trung tâm là hỗ trợ phần các công việc khác của tổ chức, trong đó có việc quản lý các tài sản như máy tính và giấy phép phần mềm và cung cấp các dịch vụ như điện thoại, quản lý người dùng và cơ sở hạ tầng. Điều này đúng với các tổ chức hiệu năng cao và cũng đúng với các tổ chức hiệu năng thấp. Sự khác biệt nằm ở cung cách quản lý và cung cấp các dịch vụ này.

Trước đây, các công ty thường dựa vào các gói do các hãng bên ngoài (như Oracle, IBM và Microsoft) cung cấp để bảo đảm các thành phần cơ sở hạ tầng như cơ sở dữ liệu, lưu trữ và công suất máy tính. Lẽ ra đã không có công ty nào có thể bỏ lỡ cơ hội chuyển sang kết cấu điện toán tiện ích được gọi là “điện toán đám mây”. Tuy nhiên, mặc dù rất ít công ty có thể né tránh bước chuyển đổi này, nhưng nhiều công ty lại không thực hiện điều đó một cách đúng mức.

Để thành công, các tổ chức IT phải thực hiện một trong hai cách: hoặc là thuê ngoài các dịch vụ hạ tầng hay nền tảng cơ sở (IaaS hoặc PaaS) hoặc là tự mình xây dựng và phát triển.

Mặc dù, việc dựa vào các nhà cung cấp đám mây bên ngoài mang theo nhiều rủi ro khác biệt so với tự quản lý cơ sở hạ tầng, nhưng nhiều lý do thường được đưa ra để giải trình cho việc xây dựng một “đám mây riêng” lại không vượt qua được sự rà soát. Các nhà lãnh đạo nên xem xét những lập luận phản đối về chi phí và bảo mật dữ liệu với sự hoài nghi: có hợp lý không khi tin rằng nhóm bảo mật thông tin của công ty bạn sẽ làm việc tốt hơn cả Amazon, Microsoft hay Google hay tổ chức của bạn có thể mua được phần cứng rẻ hơn không?

Do việc đột nhập vào các mạng doanh nghiệp hiện nay đã là chuyện thường ngày (và đôi khi còn được nhà nước tài trợ), quan điểm cho rằng bằng cách nào đó thì dữ liệu sẽ an toàn hơn sau bức tường lửa của doanh nghiệp là điều vô lý. Cách duy nhất để đảm bảo an toàn dữ liệu một cách hiệu quả là mã hóa vững chắc kết hợp với hàng rào an ninh nghiêm ngặt đối với hoạt động quản lý chủ chốt và kiểm soát truy cập. Thực hiện điều này qua điện toán đám mây có hiệu quả tương đương như trong mạng của công ty. Nhiều tổ chức đã thuê ngoài đội hoạt động IT trong nhiều năm; ngay cả CIA cũng thuê Amazon xây dựng và vận hành một số trung tâm dữ liệu. Nhiều quốc gia đang cập nhật các quy định để chính thức cho phép việc lưu trữ dữ liệu vào các hạ tầng do bên ngoài quản lý.

Có hai lý do chính đáng cần phải cẩn trọng về những đám mây công cộng. Rủi ro đầu tiên là việc chỉ theo một nhà cung cấp; bạn có thể giảm thiểu rủi ro này bằng cách thận trọng trong lựa chọn kiến trúc. Thứ hai là vấn đề chủ quyền dữ liệu. Bất kỳ công ty nào lưu trữ dữ liệu trong đám mây “đều phải tuân thủ luật pháp của quốc gia chủ quản máy chủ và luật địa phương của họ về cách thức bảo vệ dữ liệu, dẫn đến nguy cơ xung đột về luật đối với chủ quyền dữ liệu. Tác động của các nghĩa vụ pháp lý chồng chéo này phụ thuộc vào luật pháp cụ thể của các quốc gia, mối quan hệ và các thoả thuận giữa các chính phủ.”

Tuy nhiên, có những lý do rất thuyết phục để tiếp cận các nhà cung cấp đám mây công cộng, trong đó có chi phí thấp hơn và tốc độ phát triển nhanh hơn. Cụ thể, đám mây công cộng cho phép các nhóm kỹ thuật ngay lập tức sử dụng cơ sở hạ tầng của mình theo nhu cầu. Điều này làm giảm đáng kể thời gian và chi phí phát triển các dịch vụ mới và mở rộng các dịch vụ hiện tại. Trong khi đó, nhiều công ty tuyên bố đã triển khai “đám mây riêng” vẫn yêu cầu các kỹ sư phải nộp phiếu yêu cầu để được sử dụng các môi trường kiểm thử và sản xuất, và phải mất vài ngày hoặc vài tuần để được đáp ứng yêu cầu.

Bất kỳ dự án triển khai đám mây nào không giúp các kỹ sư có khả năng sử dụng API để tự bảo đảm các môi trường hoặc triển khai hoạt động ngay lập tức theo yêu cầu đều phải bị coi là thất bại. Tiêu chí duy nhất đánh giá sự thành công của việc triển khai đám mây riêng nên là sự gia tăng đáng kể hiệu năng IT tổng thể, được tính toán dựa trên các thông số về năng suất và độ ổn định như đã trình bày ở trên: thời lượng sản xuất thay đổi, tần suất triển khai, thời gian khôi phục dịch vụ và tỷ lệ thất bại thay đổi. Điều này sẽ giúp đem lại chất lượng cao hơn và chi phí thấp hơn, đồng thời giải phóng vốn để đầu tư cho phát triển sản phẩm mới và cải thiện các dịch vụ và cơ sở hạ tầng hiện có.

Lựa chọn thay thế cho việc sử dụng một nhà cung cấp bên ngoài là phát triển nền tảng phân phối dịch vụ tại chỗ của chính bạn. Nền tảng phân phối dịch vụ (SDP) cho phép bạn tự động hóa tất cả các hoạt động thường lệ liên quan đến việc xây dựng, kiểm thử và triển khai các dịch vụ, bao gồm cả cung cấp và quản lý liên tục các dịch vụ cơ sở hạ tầng. Đó cũng là nền tảng để vận hành các đường ống triển khai liên quan đến việc xây dựng, kiểm thử và triển khai các dịch vụ cá nhân. Cuốn The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems (tạm dịch: Thực hành quản lý hệ thống đám mây: Thiết kế và vận hành các hệ thống phân bổ rộng) là một cẩm nang tuyệt vời hướng dẫn việc thiết kế và vận hành nền tảng phân phối dịch vụ.

Tuy nhiên, những công ty thành công trong việc xây dựng SDP riêng (theo tiêu chí trên) thường không thực hiện theo lộ trình IT truyền thống khi mua sắm, tích hợp và vận hành các gói thương mại.

Thay vào đó, họ sử dụng kết cấu phát triển sản phẩm được mô tả trong cuốn sách này để xây dựng và phát triển một SDP; họ ưa sử dụng các thành tố nguồn mở làm nền tảng. Cách tiếp cận này đòi hỏi phải tái trang bị và tái sắp xếp biện pháp IT để tập trung vào việc khám phá các nền tảng mới bằng cách kiểm thử chúng với một nhóm nhỏ các khách hàng nội bộ (như đã thảo luận trong Phần II) với mục đích sớm phân phối giá trị và tạo ra hiệu năng cao hơn nền tảng của các nhà cung cấp bên ngoài. Các sản phẩm đã được phê chuẩn cần được phát triển dựa trên các nguyên tắc được mô tả trong Phần III, sử dụng các nhóm sản phẩm liên chức năng để đánh giá mức độ thành công của chúng bằng các thông số hiệu năng IT nói trên.

Sẵn sàng cho thảm họa

Các tổ chức chọn cách tự quản lý SDP riêng phải đặc biệt coi trọng tính liên tục trong kinh doanh. Amazon, Google và Facebook thường xuyên đưa lỗi vào hệ thống sản xuất của họ để kiểm tra các quy trình khắc phục thảm họa của các hệ thống đó. Khi thực hiện các biện pháp này, được gọi là Game Days tại Amazon và Disaster Recovery Testing (DiRT) ở Google, một nhóm chuyên trách được tập hợp lại để lập kế hoạch và triển khai thực hiện một kịch bản thảm họa.

Họ thường ngắt điện các trung tâm dữ liệu và cắt kết nối cáp quang đến các văn phòng hay trung tâm dữ liệu. Kiểu làm này gây hậu quả thực sự nhưng có thể hủy bỏ trong trường hợp có nguy cơ thất bại không thể kiểm soát. Người ta hy vọng hững người vận hành các dịch vụ bị ảnh hưởng sẽ tuân thủ các thỏa thuận cấp dịch vụ (SLA) của mình và sự gián đoạn hoạt động phải được lên kế hoạch cẩn thận để không vượt quá giới hạn cần thiết để vận hành dịch vụ. Điều quan trọng là việc rút kinh nghiệm theo hướng không đổ lỗi phải được thực hiện sau mỗi lần tập dượt (xem Chương 11) và những cải tiến đưa ra phải được kiểm thử sau đó.

Kripa Krishnan, Giám đốc Chương trình phụ trách các bài tập DiRT của Google nhận xét rằng “để các sự kiện kiểu DiRT thành công, một tổ chức trước tiên cần hiểu rằng lỗi hệ thống và lỗi quy trình là một phương tiện để học hỏi. Mọi thứ đều có thể bị lỗi. Khi mọi việc diễn ra như vậy, cần chú trọng đến việc sửa lỗi thay vì tập trung quở trách một cá nhân hoặc một nhóm vì một lỗi của các hệ thống phức tạp... Chúng tôi thiết kế các cuộc kiểm thử cần sự tham gia của các kỹ sư từ vài nhóm khác nhau, những người thường không có cơ hội tương tác với nhau. Bằng cách đó, nếu thực sự xảy ra một thảm hoạ quy mô lớn, những người này đã thiết lập được mối quan hệ công việc bền chặt.

Netflix áp dụng ý tưởng này một cách hết sức hợp lý bằng cách vận hành một nhóm dịch vụ được gọi là Đội quân Simian (Simian Army²), dẫn đầu là Chaos Monkey, một dịch vụ đều đặn tắt các máy chủ để kiểm thử sự bền bỉ của môi trường vận hành. Giống như nhiều hệ thống Netflix khác, phần mềm hỗ trợ Simian Army là nguồn mở và có trên GitHub³. Các tổ chức không đủ dũng cảm để thực hiện các bài tập đưa lỗi giống như thật vào hệ thống ít nhất một năm một lần thì không nên tự phát triển các dịch vụ hạ tầng riêng cho mình – ít nhất là không cho các hệ thống trọng yếu.

2 The Simian Army là tập hợp các đám mây nguồn mở để kiểm thử các công cụ được tạo ra bởi công ty truyền hình trực tuyến Netflix. Các công cụ này cho phép các kỹ sư kiểm thử sự tin cậy, khả năng bảo mật, sự bền bỉ và khả năng khôi phục của các dịch vụ đám mây mà Netflix vận hành trên hạ tầng dịch vụ mạng Amazon AWS. (ND)

³ GitHub là một dịch vụ cung cấp kho lưu trữ mã nguồn Git dựa trên nền web cho các dự án phát triển phần mềm. (ND)

Cuối cùng, những tổ chức phát triển các dịch vụ cơ sở hạ tầng riêng phải trao cho khách hàng nội bộ quyền lựa chọn sử dụng hoặc không sử dụng các dịch vụ này. Các doanh nghiệp dựa vào việc tiêu chuẩn hóa các dịch vụ và tài sản do bộ phận vận hành IT cung cấp để quản lý các khoản chi phí hỗ trợ, chẳng hạn như việc duy trì danh sách các công cụ đã được phê duyệt và các thành tố cơ sở hạ tầng mà các nhóm có thể lựa chọn. Tuy nhiên, các xu hướng như là việc nhân viên mang các thiết bị riêng để làm việc (BYOD) và các nhóm phát triển sản phẩm sử dụng các thành phần nguồn mở không đạt chuẩn như cơ sở dữ liệu NoSQL, là một thách thức đối với mô hình này. Chúng ta đã chứng kiến một số trường hợp cần có các thành phần nguồn mở để đạt được mức độ hiệu năng, khả năng duy trì và bảo mật theo yêu cầu của khách hàng nhưng lại bị các bộ phận IT phản đối. Việc cố gắng ép các sản phẩm phải sử dụng các gói hiện hành sẽ dẫn đến sự lãng phí về thời gian và tiền bạc.

Cách giải quyết đúng cho vấn đề này là cho phép các nhóm sản phẩm sử dụng các công cụ và thành tố mà họ muốn, nhưng yêu cầu họ phải chấp nhận rủi ro và chịu các chi phí quản lý và vận hành các sản phẩm, dịch vụ mà họ xây dựng. Xin nhắc lại tuyên bố của Werner Vogels, Giám đốc Công nghệ của Amazon: “Bạn xây dựng nó, bạn vận hành nó.” Hãy nhớ lại khái niệm tinh gọn về hiệu năng tối ưu ở Chương 7: “Cung cấp giá trị khách hàng sao cho tổ chức không phải gánh những chi phí không cần thiết; công việc thông suốt không bị trì hoãn; tổ chức tuân thủ 100% luật pháp của địa phương, liên bang và nhà nước; tổ chức đáp ứng mọi yêu cầu mà khách hàng đưa ra; và nhân viên được an toàn và được tôn trọng. Nói cách khác, công việc cần được thiết kế nhằm loại bỏ sự trì hoãn, cải tiến chất lượng và giảm chi phí, nỗ lực và sự thất vọng không cần thiết”. Cần coi các quy trình cản trở hiệu năng tối ưu là mục tiêu của tiến trình cải tiến.

QUẢN LÝ CÁC HỆ THỐNG HIỆN HÀNH

Một nền tảng phân phối dịch vụ, dù được xây dựng tại chỗ hoặc do một nhà cung cấp bảo đảm, đều phải đảm bảo được chuẩn hóa và giúp giảm chi phí khi vận hành các hệ thống mới. Tuy nhiên, nó sẽ không giúp giảm bớt mức độ phức tạp của những hệ thống hiện hành. Nhiều hệ thống hiện hành đang là một trong những yếu tố lớn nhất làm hạn chế khả năng tiến triển nhanh chóng của các bộ phận IT trong doanh nghiệp.

Đối với những bộ phận vận hành phải duy trì hàng trăm hoặc hàng ngàn dịch vụ hiện hành, ngay cả việc chỉ cung cấp một tính năng đơn giản mới cũng có thể động chạm đến nhiều hệ thống và bất kỳ sự thay đổi nào đối với quá trình sản xuất đều dẫn đến nhiều rủi ro. Việc xây dựng môi trường kiểm thử tích hợp cho những thay đổi như vậy thường rất tốn kém, ngay cả việc tái tạo một phần môi trường sản xuất cũng mất rất nhiều công sức (và với mục đích kiểm thử, thường rất khó biết cần tái tạo bao nhiêu và chi tiết đến mức nào). Kết hợp điều này với các nhóm chức năng tách biệt, việc thuê ngoài và các nhóm phân tán có nhiều sự ưu tiên khác nhau, chúng ta sẽ nhanh chóng nhận thấy mình bị bó cả chân cả tay.

Trong phần này, chúng tôi trình bày ba chiến lược để giảm thiểu vấn đề này. Chiến lược ngắn hạn là xây dựng tính minh bạch của các vấn đề ưu tiên và cải thiện việc giao tiếp giữa các nhóm làm việc trên các hệ thống này. Giải pháp trung hạn là xây dựng các lớp trừu tượng (abstraction layer⁴) trên các hệ thống khó thay đổi và tạo ra các phép thử kép (test double⁵) cho các hệ thống phải tích hợp với chúng. Giải pháp dài hạn là thúc đẩy việc kiến trúc lại các hệ thống với mục đích tăng tốc độ di chuyển ở quy mô phù hợp.

4 Trong tin học, abstraction layer hay abstraction level là một cách ẩn giấu việc thực hiện các chi tiết của một nhóm chức năng cụ thể, cho phép phân chia các mối quan tâm nhằm hỗ trợ khả năng tương tác và tính độc lập về nền tảng. (ND)

⁵ Trong tin học, để nâng cao chất lượng phần mềm, các nhà lập trình sử dụng một kỹ thuật gọi là kiểm thử cục bộ tự động, tức là sử dụng các dụng cụ hoặc thủ tục giống như những dụng cụ hoặc thủ tục dự kiến cho lưu hành, nhưng là phiên bản đơn giản hóa nhằm giảm tính phức tạp và tạo thuận lợi cho việc kiểm thử. Test double là một thuật ngữ khái quát được sử dụng cho những dụng cụ hay thủ tục này. (ND)

Giải pháp ngắn hạn − xây dựng tính minh bạch của các vấn đề ưu tiên và cải thiện việc giao tiếp − rất quan trọng và có thể đem lại hiệu quả cao. IT phải phục vụ nhiều bên có xung đột về các vấn đề ưu tiên.

Người chiến thắng thường là người lớn tiếng nhất hay có mối quan hệ chính trị tốt nhất, chứ không được quyết định dựa trên mô hình kinh tế như Chi phí Trì hoãn (thảo luận trong Chương 7). Điều quan trọng là tất cả các cấp trong tổ chức phải có được hiểu biết chung về những ưu tiên hiện tại. Biện pháp đơn giản là định kỳ hằng tuần hoặc hằng tháng tổ chức cuộc họp các bên liên quan chủ chốt, bao gồm tất cả khách hàng của IT, và đưa ra danh sách các ưu tiên trong khoảng một trang giấy. Giao tiếp thường xuyên giữa những người có trách nhiệm đối với các hệ thống theo từng cặp cũng là điều hết sức cần thiết.

KẾT NỐI THEO TỪNG CẶP ĐÒI HỎI PHẢI GIAO TIẾP THƯỜNG XUYÊN

Một công ty du lịch lớn muốn cung cấp liên tục các tính năng mới cho trang web của họ. Tuy nhiên, trang web này lại cần dung hòa với hệ thống đặt vé kiểu cũ. Thông thường, các tính năng mới bị trì hoãn do phụ thuộc vào những thay đổi của hệ thống đặt vé trong khi hệ thống này phải sáu tháng mới được cập nhật một lần. Điều này khiến công ty tổn hại lớn do chi phí cho những cơ hội bị tuột mất.

Họ đã thực hiện một phương pháp đơn giản để giảm nhẹ vấn đề là cải thiện việc giao tiếp giữa các nhóm. Giám đốc sản phẩm của trang web thường xuyên gặp gỡ giám đốc chương trình phụ trách hệ thống đặt vé. Họ so sánh những vấn đề cần lưu ý về những lần ban hành sắp tới và phát hiện những yếu tố phụ thuộc lẫn nhau. Họ tìm cách điều chỉnh lịch làm việc để giúp nhau đưa ra các tính năng đúng thời gian hoặc bỏ lại các tính năng mà họ không thể phân phối.

Giải pháp trung hạn là tìm cách mô phỏng các hệ thống không thay đổi thường xuyên mà chúng ta phải tích hợp. Có một cách là sử dụng các phiên bản mô hình hóa các hệ thống này. Một cách khác là xây dựng phép thử kép mô phỏng hệ thống từ xa cho các mục đích kiểm thử (Hình 14-2). Điều quan trọng là chúng ta phải nhớ rằng mình không nhắm tới việc tái tạo chính xác môi trường sản xuất thực. Chúng ta cố gắng phát hiện và xử lý từ sớm phần lớn những vấn đề gây khó khăn cho việc tích hợp trước khi tiến tới một môi trường mô phỏng đầy đủ.

Bằng cách mô phỏng các hệ thống từ xa hoặc vận hành chúng trong môi trường ảo, mỗi ngày chúng ta đều có thể tích hợp và tiến hành kiểm thử ở cấp độ hệ thống để đánh giá những thay đổi. Điều này giảm bớt số lượng công việc chúng ta phải làm trong một môi trường tích hợp chuẩn xác.

Giải pháp dài hạn là kiến trúc các hệ thống theo cách để chúng ta có thể di chuyển nhanh, cụ thể là có thể triển khai độc lập các bộ phận của hệ thống theo ý muốn, mà không phải trải qua các bước triển khai phức tạp. Tuy nhiên, điều này đòi hỏi phải tái kiến trúc cẩn thận bằng cách sử dụng kết cấu ứng dụng sống bám được mô tả trong Chương 10.

Hình 14-2. Mô phỏng các hệ thống từ xa phục vụ mục đích kiểm thử, được sự đồng ý của Martin Fowler

Khi bắt đầu quá trình này, bước quan trọng đầu tiên là lập đồ họa các dịch vụ của bạn và những kết nối giữa chúng. Dựa vào vòng đời đổi mới (xem Chương 2) và giá trị mà mỗi dịch vụ cung cấp cho tổ chức, chúng ta có thể mô tả giá trị và vòng đời trên hai trục, sau đó xây dựng bản đồ chuỗi giá trị để hiển thị từng sản phẩm và các thành phần đi kèm (Hình 14-3). Để xây dựng bản đồ chuỗi giá trị, hãy chọn một sản phẩm và đặt nó vào vị trí thích hợp ở trên đỉnh của một biểu đồ mới. Sau đó vẽ những dịch vụ mà sản phẩm phụ thuộc vào và những kết nối giữa chúng. Cách này có thể được thực hiện rất nhanh và chi phí thấp bằng cách sử dụng một tấm bảng trắng cùng với các phần ghi chú.

Hình 14-3. Bản đồ chuỗi giá trị, được sự đồng ý của Simon Wardley

Bước tiếp theo là xây dựng phiên bản “tương lai” của biểu đồ này theo các nguyên tắc sau:

Sử dụng các nhà cung cấp dịch vụ phần mềm cho tất cả các dịch vụ “tiện ích” như: bảng lương, quản lý nhà cung cấp, thư điện tử, kiểm soát phiên bản... Nếu có những hệ thống mà chúng ta không thể di chuyển sang đám mây, chúng ta nên sử dụng các gói phần mềm thương mại bán sẵn (COTS).

Đối với các dịch vụ và ứng dụng chiến lược cung cấp lợi thế cạnh tranh, chúng ta nên phát triển phần mềm tùy chỉnh theo nhu cầu khách hàng như được mô tả ở phần sau của cuốn sách. Bằng mọi giá phải tránh tất cả các cám dỗ để sử dụng các gói phần mềm bán sẵn cho các khả năng này.

Các hệ thống ghi lưu thường là khó thay đổi nhất và là sự kết hợp của các COTS và các hệ thống cũ hơn, trong đó có các máy tính trung tâm. Điều này thường đòi hỏi phải có sự gia cố và chiết tách để giảm chi phí duy trì và tích hợp với chúng. Theo thời gian, chúng có thể bị siết chặt nếu cần thiết.

Khi sử dụng COTS, điều quan trọng là không tùy chỉnh các gói này. Chúng tôi không thể nói hết được các vấn đề và rủi ro liên quan đến việc tùy chỉnh COTS. Khi các tổ chức bắt đầu tùy chỉnh, thật khó để dừng lại, trong khi việc tùy chỉnh các gói COTS rất tốn kém vì phải xây dựng và duy trì chúng theo thời gian. Một khi bạn đã vượt quá một số lượng tùy chỉnh nhất định, nhà cung cấp ban đầu sẽ không còn hỗ trợ gói đó nữa. Việc nâng cấp các gói được tùy chỉnh gây ra nhiều tổn thất, khó mà thay đổi nhanh chóng và an toàn với một hệ thống COTS được tùy chỉnh.

Thay vào đó, hãy thay đổi các quy trình kinh doanh để phù hợp với những cách làm sáng tạo do các gói COTS cung cấp. Bất cứ khi nào lựa chọn giải pháp dựa trên COTS, bạn sẽ có một danh sách các tính năng cần thực hiện hoặc các lỗi cần sửa. Những điều này luôn cần phải được coi là đầu vào của hoạt động quản lý thay đổi quy trình kinh doanh. Việc thay đổi quy trình kinh doanh rẻ và hiệu quả hơn nhiều so với thay đổi các gói COTS để phù hợp với quy trình hiện hành. Nếu bạn bắt đầu tiến trình tùy chỉnh, hãy lấy lần phát hành gói COTS tiếp theo như là một cơ hội để chuyển sang một phiên bản mới, không tùy chỉnh giống như Telstra (Hãng viễn thông lớn nhất của Australia) đã làm khi chuyển từ một phần mềm Remedy tùy chỉnh nhiều sang một loại hoàn toàn cơ bản.

Chuyển từ trạng thái hiện tại của bạn sang trạng thái tương lai có thể sẽ mất nhiều năm. Đối với tất cả những thay đổi ở quy mô lớn, cách tiến hành đúng đắn là chia khối lượng công việc to lớn, đồ sộ thành từng bước nhỏnhằm bảo đảm có lợi ích cao nhất xét theo nghĩa cải thiện kết quả kinh doanh và khách hàng.

CHƯƠNG TRÌNH TỐI GIẢN HÓA CỦA TẬP ĐOÀN SUNCORP THEO SCOTT BUCKLEY VÀ JOHN KORDYBACK

Tập đoàn Suncorp của Australia có những kế hoạch đầy tham vọng nhằm loại bỏ những hệ thống chính sách bảo hiểm tổng thể trước đây, cải tiến nền tảng ngân hàng cốt lõi và khởi động một chương trình vận hành hoàn hảo. Matt Pancino, hiện là CEO của Các Hệ thống Kinh doanh Suncorp, cho biết: “Bằng cách loại bỏ các hệ thống trùng lặp hoặc cũ kĩ, Suncorp nhắm đến mục đích giảm chi phí vận hành và tái đầu tư những khoản tiết kiệm này vào các kênh kỹ thuật số mới”.

Các phương pháp tinh gọn và cải tiến liên tục là những chiến lược cần thiết để cung cấp chương trình tối giản hóa. Suncorp đang đầu tư thành công vào các khuôn khổ kiểm thử tự động để hỗ trợ việc phát triển, thiết lập cấu hình, duy trì và nâng cấp các hệ thống một cách nhanh chóng. Những kỹ thuật này rất quen thuộc với người dùng các nền tảng công nghệ mới, đặc biệt là trong không gian kỹ thuật số, nhưng Suncorp đang áp dụng thành công các phương pháp tinh gọn và linh hoạt vào các hệ thống “siêu máy tính”.

Kỹ thuật phân phối

Trong lĩnh vực kinh doanh bảo hiểm, Suncorp đang tiến hành hợp nhất các hệ thống máy tính lớn chuyên về chính sách bảo hiểm lớn và phức tạp thành một hệ thống nhằm hỗ trợ các quy trình kinh doanh chung trong toàn tổ chức và tăng doanh số bảo hiểm thông qua các kênh trực tiếp. Một số bộ phận chủ chốt đã có sẵn trong chương trình “xây dựng các khối”, chương trình cung cấp một khuôn khổ kiểm thử chức năng cho hệ thống chính sách máy tính lớn cốt lõi, kỹ thuật phân phối linh hoạt và cách tiếp cận chung đối với việc tích hợp hệ thống dựa trên các dịch vụ web.

Trong năm đầu tiên của chương trình tối giản hóa, việc kiểm thử đã được mở rộng để hỗ trợ việc tích hợp hệ thống chính sách máy tính lớn với các kênh kỹ thuật số mới và các hệ thống định giá. Các tiêu chuẩn tự động chấp nhận đã được phát triển trong khi các hệ thống khác đang trong quá trình phát triển. Điều này giúp giảm đáng kể thời gian kiểm thử việc tích hợp hệ thống định giá và đánh giá rủi ro mới với nhiều loại chính sách khác nhau. Kiểm thử tự động cũng hỗ trợ việc quản lý và xác định chính sách khách hàng thông qua các kênh khác nhau như kênh trực tuyến hoặc tổng đài.

Kiểm thử hồi quy các chức năng cốt lõi hằng đêm đã bắt kịp tốc độ phát triển và hỗ trợ cả kiểm thử chức năng và tích hợp liên hệ thống. Vì phát hiện được các sai sót trong các kịch bản kinh doanh đầu cuối nên các giải pháp phản ứng được quản lý theo giờ hoặc ngày, chứ không phải theo tuần như thường thấy ở các hệ thống doanh nghiệp lớn hơn.

Kết quả

Trong quá trình này, Suncorp đã giảm đượctừ 15 hệ thống bảo hiểm nhân thọ và bảo hiểm cá nhân phức tạp xuống còn 2 hệ thống và loại bỏ 12 hệ thống cũ. Việc nâng cấp kỹ thuật được thực hiện một lần và triển khai trên tất cả các nhánh. Tập đoàn có một mã gốc duy nhất cho các trang web trực diện khách hàng giới thiệu tất cả nhãn hàng và sản phẩm khác nhau. Điều này cho phép đáp ứng nhanh hơn nhu cầu khách hàng và buộc mỗi nhóm dôi dư riêng rẽ phải chịu trách nhiệm cho một trang web.

Xét trên quan điểm kinh doanh thì hệ thống đơn giản hơn này đã cho phép tái thiết kế và bố trí hợp lý 580 quy trình kinh doanh. Lúc này, các nhóm có thể cung cấp các dịch vụ mới hoặc cải tiến theo nhu cầu, thay vì phải cải thiện từng nhãn hàng riêng rẽ. Điều đó giúp giảm thời gian triển khai các sản phẩm và dịch vụ mới, chẳng hạn như bảo hiểm y tế cho khách hàng APIA hoặc hỗ trợ dọc tuyến cho khách hàng AAMI.

Với việc đầu tư cho tối giản hóa và quản lý các hệ thống cốt lõi, tập đoàn Suncorp có thể gia tăng đầu tư cho tất cả các điểm tiếp xúc với khách hàng. Với cả công nghệ và kỹ thuật kinh doanh, Suncorp đã tăng tốc độ tối giản hóa với nhiều nhãn hàng hiện đang sử dụng chung hạ tầng, dịch vụ và quy trình.

Báo cáo thường niên của Suncorp năm 2014 chỉ rõ: “việc tối giản hóa đã cho phép Tập đoàn vận hành một nền tảng chi phí khả biến hơn với khả năng mở rộng các nguồn lực và dịch vụ theo nhu cầu của thị trường và doanh nghiệp. Hoạt động tối giản hóa dự kiến sẽ đạt mức tiết kiệm 225 triệu đô-la vào năm 2015 và 265 triệu đô-la vào năm 2016.”

KẾT LUẬN

Nếu chúng ta muốn cạnh tranh trong một thế giới có vòng đời sản phẩm ngắn chưa từng có thì IT trung tâm cần phải là đối tác tin cậy của các đơn vị kinh doanh chứ không phải là trung tâm đánh giá chi phí đặt hàng. Đổi lại, IT cần đạt được mức thông lượng cao hơn trong khi không ngừng cải thiện độ ổn định, chất lượng và giảm chi phí. Sự phức tạp của các môi trường IT hiện tại của doanh nghiệp, cùng với việc phải hoàn thành một số lượng lớn các công việc theo kế hoạch và đột xuất chính là những rào cản lớn để đạt được những kết quả này.

Chúng ta chỉ có thể bắt đầu giải quyết những vấn đề này khi xem xét những tác động của công việc mới đối với các hoạt động IT và coi đó là một phần không thể thiếu của vòng đời phát triển sản phẩm. Để quản lý sự phức tạp tăng thêm do việc đưa vào các sản phẩm, dịch vụ và tính năng mới, chúng ta phải bắt đầu bằng cách chuyển từ mô hình dựa trên dự án sang mô hình lấy sản phẩm là trung tâm, như được mô tả trong Chương 10. Các nhóm sản phẩm phải chịu trách nhiệm về các chi phí và thỏa thuận cấp độ dịch vụ của những hệ thống mà họ xây dựng; đổi lại, họ được tự do lựa chọn công nghệ để sử dụng và quản lý những thay đổi của mình. Bằng cách này, chúng ta giải phóng được con người và các nguồn lực trong bộ phận IT trung tâm để tập trung giảm sự phức tạp của các hệ thống và cơ sở hạ tầng của họ và xây dựng một chuỗi công cụ và nền tảng thuận lợi cho vòng đời phát triển sản phẩm mà chúng tôi đã mô tả trong cuốn sách này.

Chúng ta thường coi sản lượng và sự ổn định là yếu tố đối nghịch, tức là tăng sản lượng thì bạn sẽ làm giảm chất lượng và sự ổn định. Tuy nhiên, những mục đích này có thể bổ sung cho nhau nếu có một chiến lược đúng đắn. Giống như mọi nỗ lực cải tiến khác, chúng ta phải bắt đầu bằng cách làm rõ mục đích và xác định các chỉ số hiệu năng chính mà chúng ta quan tâm. Sau đó, chúng ta sử dụng Kata Cải tiến để hướng tới mục đích đặt ra.

Câu hỏi dành cho độc giả:

◆ Bộ phận IT coi mình là một nhà cung cấp dịch vụ, một đối tác của các đơn vị kinh doanh hay là nhân tố dẫn dắt sự đổi mới không? Các nhà lãnh đạo khác trong tổ chức nghĩ gì?

◆ Bạn có đo lường được sự thay đổi về thời lượng sản xuất, tần suất phát hành, thời gian khôi phục dịch vụ và tỷ lệ thất bại của tất cả các sản phẩm và dịch vụ không? Bạn có làm cho các nhóm nắm được tất cả những điều này không?

◆ Bạn đã ngừng bao nhiêu dịch vụ trong năm vừa qua? Bạn đã bổ sung thêm bao nhiêu? Bạn mất bao nhiêu thời gian để biết được số lượng dịch vụ và sản phẩm mà bạn đang quản lý? Bạn có chắc chắn về câu trả lời của mình? Có bao nhiêu sản phẩm và dịch vụ đang hoạt động trên các hệ thống không còn được nhà cung cấp chính thức hỗ trợ?

◆ Tổ chức của bạn mất bao lâu để phê chuẩn một yêu cầu thay đổi? Mất bao lâu để một thành phần mã nguồn mở được phê chuẩn và đưa vào sử dụng trong một môi trường sản xuất?

◆ Bạn thực hiện diễn tập phục hồi thảm họa thực tế trên các hệ thống sản xuất thường xuyên như thế nào? Quy trình thực thi các đề xuất cải tiến được rút ra sau mỗi lần tập dượt này của bạn là gì?

◆ Tất cả các lập trình viên, các nhà lãnh đạo phát triển và các kiến trúc sư có luân phiên lịch trình làm việc và thường xuyên hỗ trợ các hệ thống mà họ xây dựng?

Chương 15Hãy bắt đầu với những gì bạn có

Nếu bạn làm điều gì đó và nó trở nên khá tốt, bạn nên làm cái gì đó tuyệt vời, đừng dừng lại ở đó quá lâu. Hãy tìm ra cái để làm tiếp theo.

− STEVE JOBS

Một năm sau tính từ giờ khắc này, bạn hẳn sẽ ước, giá mà mình đã bắt đầu từ ngày hôm nay.

− KAREN LAMB

Mục đích của chúng tôi khi viết cuốn sách này là truyền cảm hứng để bạn hình dung một tương lai thay thế cho các tổ chức lớn. Một tương lai coi nhân viên, khách hàng và sản phẩm là trung tâm chiến lược của mình. Một tương lai mà ở đó một nền văn hóa và môi trường đổi mới giúp tổ chức nhanh chóng thích ứng với những nhu cầu thị trường nhiều thay đổi.

Chúng tôi đã chia sẻ những câu chuyện và bài học từ nhiều tổ chức với nền tảng và hoàn cảnh khác nhau để chứng tỏ rằng ngay cả trong những môi trường phức tạp, bạn vẫn có thể phát triển và giải quyết những vấn đề khó khăn nhất. Tuy nhiên, con đường dẫn đến thành công không phải là một con đường thẳng tắp với các biển chỉ dẫn xác định, các cột mốc và các Chỉ số đo lường hiệu năng (KPI). Các tổ chức cần cảm thấy thoải mái khi tiến lên phía trước với những thông tin không chắc chắn và không hoàn hảo, trong khi không ngừng học hỏi, điều chỉnh và phát triển con người trên con đường đó.

Rào cản lớn nhất cho thay đổi thành công cách mà bạn làm việc là niềm tin rằng tổ chức của bạn quá lớn hoặc quan liêu đến mức không thể thay đổi hoặc hoàn cảnh đặc biệt của bạn ngăn cản việc áp dụng các phương pháp cụ thể mà chúng ta thảo luận. Hãy luôn nhớ rằng mỗi người, mỗi nhóm và mỗi doanh nghiệp khi bắt đầu hành trình đều không biết phải đi theo con đường nào và kết thúc ra sao. Nhưng có một sự thật duy nhất mà họ chấp nhận là nếu họ không hành động thì một kết cục tiêu cực hơn là điều đương nhiên.

CÁC NGUYÊN TẮC THAY ĐỔI TỔ CHỨC

Mọi thay đổi đều rủi ro, đặc biệt là những thay đổi về tổ chức vốn liên quan đến thay đổi văn hóa – sự thay đổi khó khăn nhất trong tất cả, vì bạn tác động đến các yếu tố tạo nên bản sắc của tổ chức. Chúng tôi vẫn luôn thấy ngạc nhiên khi các nhà lãnh đạo xây dựng các chương trình “thay đổi tổ chức” mà họ mong đợi được hoàn thành trong vài tháng. Các chương trình như vậy không giúp nhận ra rằng việc biến sự đổi mới hoặc thay đổi thành một sự kiện chứ không phải là một phần của công việc hằng ngày sẽ chẳng bao giờ tạo được kết quả đáng kể hoặc lâu dài. Định kỳ cấp ngân sách cho một chương trình thay đổi mới nhằm đối phó với các vấn đề hiện tại, những thay đổi ban lãnh đạo hay các xu hướng thị trường mà không am hiểu văn hóa thực nghiệm sẽ chỉ đạt được sự thay đổi tăng dần trong ngắn hạn, nếu có (Hình 15-1). Các tổ chức sẽ nhanh chóng quay trở lại trạng thái trước đó. Thay vào đó, chúng ta phải tạo ra một nền văn hóa cải tiến liên tục thông qua hành động có chủ đích và liên tục của mọi người trong tổ chức.

Hình 15-1: Thực tế của các chương trình thay đổi “dựa trên sự kiện”

Nếu tổ chức của bạn đang phải đợi một sự kiện để kích thích sự thay đổi, thì bạn đang gặp rắc rối. Trong nền kinh tế cạnh tranh và môi trường hiện nay, ý thức về sự cấp bách phải là một trạng thái thường trực. Lo lắng về sự sống còn luôn tồn tại trong các tổ chức hàng đầu, như chúng tôi đã mô tả trong Chương 11. Tuy nhiên, như Schein đã lưu ý, sử dụng điều đó làm động lực cho sự thay đổi liên tục là không hiệu quả. Con đường duy nhất để có được một nền văn hóa cải tiến liên tục là tạo ra một môi trường luôn nhìn nhận việc học hỏi những kỹ năng mới và nhu cầu trở nên giỏi hơn với những gì chúng ta làm là chính đáng và được sự ủng hộ của ban quản lý và lãnh đạo, nhờ đó giảm sự lo lắng về học hỏi. Chúng ta có thể sử dụng phương pháp Kata Cải tiến, được trình bày trong Chương 6, để xây dựng nền văn hóa này và thúc đẩy cải tiến liên tục (Hình 15-2).

Để phổ biến Kata Cải tiến trong toàn tổ chức, các nhà quản lý phải học hỏi và triển khai một kỹ thuật bổ sung có tên là Kata Chỉ dẫn (Coaching Kata). Để bắt đầu hành trình, một đội ngũ tiên phong bao gồm một nhà đỡ đầu là lãnh đạo – lý tưởng là CEO – triển khai thí điểm Kata Chỉ dẫn và Kata Cải tiến. Khi nhóm này định hướng việc tiếp nhận rộng rãi hơn trong tổ chức, họ bắt buộc phải hiểu rõ cách thức vận hành của các phương pháp trên.

Cẩn trọng với những trở ngại sau:

◆ Tiếp nhận Kata Cải tiến đòi hỏi phải thay đổi đáng kể các hành vi ứng xử ở tất cả các cấp trong tổ chức. Kata Chỉ dẫn được sử dụng để hướng dẫn cho mọi người về Kata Cải tiến, nhưng việc triển khai Kata Chỉ dẫn như thế nào trong một tổ chức vẫn là điều quan trọng.

Hình 15-2: Phát triển và thích nghi liên tục với sự thay đổi

◆ Tiến hành các cuộc kiểm thử rất khó và đòi hỏi tính kỷ luật cao. Để thực nghiệm tốt, phải có kỹ năng và tư duy tốt. Về bản chất, con người có xu hướng đi thẳng vào các giải pháp thay vì phải thống nhất trước các mục tiêu (kết quả) có thể đo lường được và sau đó làm việc trong các chu kỳ nhanh – theo chúng tôi, “nhanh” ở đây là theo giờ hoặc theo ngày – để đưa ra các giả thiết, kiểm thử và học hỏi từ kết quả. Hiểu biết nền tảng về cách thiết kế và tiến hành các thực nghiệm trong bối cảnh phát triển sản phẩm vẫn ở các giai đoạn đầu, còn các kỹ năng và kỹ thuật cần thiết thì chưa được biết đến hoặc hiểu rõ một cách rộng rãi.

◆ Hãy đảm bảo rằng bạn có đủ năng lực thực hiện Kata Cải tiến.

Một trong những trở ngại lớn nhất mà các nhóm phải đối mặt khi cố gắng lên lịch trình công tác cải tiến là công việc này thường bị coi là làm sao nhãng công việc phân phối. Đây là một sai lầm. Bạn cần thực hiện việc này sớm và quyết liệt. Trường hợp của HP FutureSmart cho thấy, lý do khiến công việc phân phối tiến triển chậm chạp là do những công việc không-tạo- thêm-giá-trị chiếm đến 95% chi phí của họ. Điều quan trọng có ý nghĩa sống còn đối với các nhà điều hành, tức các giám đốc hay cấp phó của họ, là phải bảo đảm rằng các nhóm hạn chế tiến độ công việc của mình trong tiến trình, như được mô tả trong Chương 7, để dành thời gian cho công việc cải tiến.

◆ Cũng như với tất cả các phương pháp khác, sự tiến bộ sẽ bấp bênh trong giai đoạn đầu khi mọi người còn đang học hỏi cách làm việc theo phương pháp mới. Mọi thứ sẽ tồi tệ hơn trước khi trở nên tốt lên. Sự phản kháng là điều thường thấy khi mọi người học các kỹ năng mới và một số sẽ nản chí khi những kỹ năng mới này trái ngược với các thói quen và hành vi hiện tại của họ.

Hướng tới mục tiêu triển khai chiến lược

Mặc dù chúng ta đã thảo luận về Kata Cải tiến với tư cách một phương pháp thúc đẩy cải tiến liên tục ở cấp độ tổng quan, nhưng nó có thể được áp dụng ở mọi cấp độ từ các nhóm cá nhân cho đến việc hoạch định chiến lược. Để áp dụng Kata Cải tiến ở cấp độ hoạch định chiến lược, hãy bắt đầu bằng việc thống nhất mục đích của tổ chức. Mục tiêu chiến lược mà chúng ta nhắm đến để phục vụ khách hàng của mình là gì? Lúc này, những người tham gia hoạch định chiến lược phải xác định và thống nhất về định hướng chung của công ty – tức là xác định kim chỉ nam của chúng ta.

Bước tiếp theo là tìm hiểu và làm rõ tình hình hiện tại của tổ chức. Những người tham gia hoạch định chiến lược cần xác định những vấn đề cần được giải quyết và thu thập dữ liệu để hiểu rõ hơn từng vấn đề. Thông thường, ngay cả các tổ chức lớn cũng có giới hạn năng lực và chỉ có thể quản lý một số sáng kiến tại một thời điểm nhất định; chọn lựa những gì không cần tập trung và đảm bảo rằng việc nhóm kiên định với quyết định của mình là việc rất quan trọng. Một khuôn khổ kinh tế như Chi phí Trì hoãn (xem Chương 7) rất hữu ích trong tạo hứng khởi để thảo luận về sắp xếp ưu tiên công việc.

Một khi đã quyết định những vấn đề cần tập trung, chúng ta phải xác định các điều kiện mục tiêu. Những điều kiện mục tiêu này phải thể hiện rõ những dấu hiệu của thành công; đồng thời phải bao gồm các KPI để chúng ta có thể đánh giá tiến độ đạt đến mục đích của mình. Cách tiếp cận thẻ điểm cân bằng truyền thống đối với các KPI gồm bốn góc độ tiêu chuẩn: tài chính, thị trường, hoạt động và con người, tổ chức. Công ty Statoil đưa ý tưởng về cách tiếp cận thẻ điểm cân bằng vào khuôn khổ Biến tham vọng thành hành động (Chương 13) của mình, đã bổ sung thêm ba tiêu chí HSE (sức khoẻ, an toàn và môi trường). Phong trào tinh gọn dạy chúng ta phải tập trung vào giảm chi phí và cải tiến chất lượng, công tác phân phối, đạo đức và sự an toàn (những “chỉ số tinh gọn” này có thể được viết tắt là QCDMS). Bjarte Bogsnes, Phó Chủ tịch về Phát triển Quản lý Hiệu năng của Statoil, đề xuất lựa chọn 10-15 KPI và ưu tiên các mục tiêu tương quan gắn kết đầu vào với kết quả (ví dụ, chi phí đơn vị chứ không phải chi phí tuyệt đối) và dựa trên sự so sánh với chuẩn cơ bản (ví dụ, “lợi tức thu về trên số vốn đầu tư cao hơn 10% so với đối thủ cạnh tranh hàng đầu”).

Các mục tiêu ở cấp độ chiến lược sẽ hình thành định hướng cho cấp độ tổ chức tiếp theo. Định hướng này sẽ phải trải qua quy trình Kata Cải tiến của chính nó. Sau đó, các mục tiêu ở cấp độ này lại hình thành định hướng cho cấp tổ chức tiếp theo, như thể hiện trong Hình 15-3. Tiến trình này, điều cho phép chúng ta đưa ra các mục tiêu và quản lý các nguồn lực và hiệu năng bằng cách tạo ra sự liên kết giữa các cấp trong tổ chức, được gọi là triển khai chiến lược (còn được gọi là Hoshin hay Hoshin Kanri; Biến tham vọng thành hành động là một biến thể của triển khai chiến lược).

QUY TRÌNH LẬP KẾ HOẠCH HOSHIN SỬ DỤNG PDCA

Hình 15-3: Chơi bóng chuyền (catchball) để thúc đẩy liên kết chiến lược giữa các mục tiêu và các sáng kiến

Quy trình hình thành sự gắn kết và thống nhất giữa các cấp là rất quan trọng. Trong triển khai chiến lược, quy trình này được mô tả như chơi bóng chuyền¹, một từ được chọn để khuyến khích các biện pháp phối hợp. Không nên chuyển trực tiếp các điều kiện mục tiêu từ cấp độ này thành định hướng cho các nhóm làm việc ở cấp độ dưới của nó; từ chơi bóng chuyền là để nhấn mạnh hơn về chiến lược, theo đó “mỗi cấp độ sẽ diễn giải hàm ý của những mục tiêu mà cấp độ trên đặt ra đối với mình”. Chúng ta cần biết rằng phản hồi từ các nhóm sẽ thúc đẩy việc cập nhật kế hoạch ở cấp độ cao hơn. Đừng phá hoại Hoshin bằng cách dùng nó chỉ để đẩy các mục tiêu xuống toàn bộ tổ chức: điểm cốt lõi của Hoshin là ở chỗ đây là một cơ chế để tạo ra sự gắn kết dựa trên sự phối hợp và các vòng lặp phản hồi ở nhiều cấp độ.

¹ Catchball là phương pháp ra quyết định mang tính tương tác cao, trong đó thông tin và các ý tưởng được lưu chuyển trong suốt tổ chức. (BTV)

Cần xác định rõ các đường chân trời hiển thị khung thời gian cho mỗi cấp độ và xếp lịch cho các phiên họp đánh giá định kỳ với các mục tiêu được cập nhật dựa trên sự tiến triển của các nhóm cấp tiếp theo. Để thực sự có hiệu quả, cuộc trao đổi này phải có tính liên chức năng, thúc đẩy hợp tác theo các chuỗi giá trị, trong và giữa các đơn vị kinh doanh. Điều này không hề dễ dàng, vì nó đòi hỏi phải trân trọng lắng nghe những ý tưởng và các mối quan tâm của những người chịu trách nhiệm về kết quả – và từ đó điều chỉnh các kế hoạch dựa trên phản hồi.

Hoạt động lập kế hoạch chiến lược cấp cao nhất có thể có đường chân trời (khung thời gian) từ 6 tháng đến vài năm tùy thuộc vào doanh nghiệp của bạn. Nên tổ chức ít nhất là hằng tháng các phiên họp đánh giá, trong đó nhóm, cùng với lãnh đạo của tất cả các nhóm có trách nhiệm báo cáo cho họ, nhóm họp để giám sát sự tiến bộ và cập nhật các điều kiện mục tiêu nhằm đáp ứng với những gì họ khám phá. Các nhóm ở các cấp độ thấp hơn thường làm việc với đường chân trời ngắn hơn và tiến hành họp đánh giá thường xuyên hơn.

Triển khai chiến lược là một công cụ tiên tiến dựa vào văn hóa và hành vi gắn kết, như chúng tôi đã mô tả trong Chương 11. Mục tiêu chính là tạo ra sự đồng thuận và gắn kết và cho phép sự tự chủ trong toàn tổ chức, theo mô hình Yêu cầu Nhiệm vụ được trình bày trong Chương 1. Chúng ta hãy cùng xem cách mà Chính phủ Anh áp dụng phiên bản triển khai chiến lược để chuyển đổi việc sử dụng các nền tảng kỹ thuật số nhằm cung cấp dịch vụ cho người dân, bắt đầu với quy mô nhỏ và dần tái lặp và phát triển.

DỊCH VỤ KỸ THUẬT SỐ CỦA CHÍNH PHỦ ANH

Chính phủ Anh, cũng giống như chính phủ của nhiều nước khác, đã nhận ra tiềm năng của Internet “vừa để giao tiếp và tương tác tốt hơn với công dân, vừa giúp tiết kiệm đáng kể”. Tuy nhiên, các dự án của chính phủ liên quan đến phát triển phần mềm đã từng có một quá khứ đáng buồn. Chính phủ Anh đã có một số dự án IT lớn tiêu tốn ngân sách khổng lồ trong khi vẫn không thể đem lại những lợi ích mong muốn, mà đỉnh điểm là sự thất bại của “Chương trình Quốc gia về IT”. Chương trình IT dân sự lớn nhất thế giới, được kỳ vọng sẽ cung cấp nền tảng hạ tầng cơ sở IT hoàn toàn mới cho cơ quan Dịch vụ Y tế Quốc gia Anh và một hệ thống lưu trữ hồ sơ bệnh nhân trên máy tính, dự trù chi phí 2,3 tỷ bảng Anh khi mới được xây dựng vào năm 2002. Hoạt động phân phối của dự án được thuê ngoài với sự tham gia của nhiều nhà cung cấp tư nhân như Accenture, Computer Sciences Corporation, Fujitsu và British Telecom. Cho đến khi bị hủy năm 2011, ước tính chương trình này đã tiêu tốn hơn 10 tỷ bảng Anh.

Theo quy trình mua sắm của chính phủ cho các dự án IT lớn, chính phủ viết một bản mô tả đầy đủ tính năng kỹ thuật của sản phẩm, mô tả chi tiết hơn một số đề xuất kinh doanh và sau đó đưa hợp đồng ra đấu thầu. Quy trình này cần từ 1 đến 2 năm trước khi có thể bắt tay vào một sản phẩm cụ thể. “Đến lúc đó,” Bộ trưởng Nội vụ Anh Francis Maude phát biểu, “gần như chắc chắn sản phẩm đó đã lỗi thời. Bạn bị mặc kẹt với một nhà cung cấp và muốn thay đổi thì rất tốn kém.”

Do các dự án IT được thuê ngoài nên mỗi cơ quan Chính phủ lại có một trang web được vận hành và thiết kế độc lập với những trải nghiệm người dùng không đồng nhất, thể hiện sự khác biệt trong tổ chức nội bộ của mỗi cơ quan. Hệ thống này phức tạp và gây khó khăn lớn cho người dùng, vì vậy họ thích sử dụng các kênh dịch vụ đắt tiền hơn như cấp cứu (walk-in²), thư tín và điện thoại.

² Walk-in là dịch vụ cho phép bệnh nhân cấp cứu đến các cơ sở y tế mà không cần đăng ký trước. (ND)

Năm 2010, Bà Martha Lane Fox, người đồng sáng lập doanh nghiệp khởi nghiệp Web.taisachnhanh.cloud, được giao nhiệm vụ làm cố vấn cho Chính phủ Anh về chiến lược cung cấp trực tuyến các dịch vụ công. Trong báo cáo, bà khuyến nghị thành lập một nhóm công chức trung tâm chịu trách nhiệm thiết kế và cung cấp sự hiện diện trực tuyến của chính phủ, thực hiện chính sách dữ liệu mở, theo đó tất cả dữ liệu của chính phủ được cung cấp thông qua các API công cộng, và chỉ định một CEO “có thẩm quyền tuyệt đối về trải nghiệm người dùng trên tất cả các dịch vụ trực tuyến của chính phủ (các trang web và các API) và có quyền chỉ đạo tất cả các chi tiêu trực tuyến của Chính phủ”. Thế là cơ quan Dịch vụ Kỹ thuật số của chính phủ Anh (GDS) ra đời. Martha Lane Fox mô tả các mục đích mà bà đề ra cho GDS như sau: “Đối với tôi, phép thử quyết định... là liệu nó có thểtrao quyền và làm cho cuộc sống đơn giản hơn cho người dân và đồng thời cho phép chính phủ loại bỏ những việc không cần thiết khác không. Tác dụng lớn nhất của việc tập trung vào mở rộng đáng kể phạm vi, tính hữu dụng và chất lượng của các giao dịch trực tuyến là: ít rắc rối hơn cho người dân và doanh nghiệp, và đem lại hiệu quả cao hơn”.

NGHIÊN CỨU ĐIỂN HÌNH: DỊCH VỤ KỸ THUẬT SỐ CỦA CHÍNH PHỦ ANH, DO GARETH RUSHGROVE THỰC HIỆN

GOV.UK là tên miền mới duy nhất cho tất cả các dịch vụ của chính quyền trung ương Anh, được đưa vào sử dụng từ tháng 10 năm 2012, trong ngày đầu tiên đã thay thế hai trong số các trang web lớn nhất của chính phủ khi đó, và tiếp tục thay thế tất cả các trang mạng của các cơ quan trung ương trong vài tháng sau đó. Cho đến năm 2014, chúng tôi sẽ đóng hàng ngàn trang web và xây dựng một dịch vụ chung duy nhất với đặc tính đơn giản hơn, rõ ràng hơn và nhanh hơn, bao gồm mọi thông tin, từ các lợi ích mà bạn có thể đủ điều kiện để hưởng cho đến hướng dẫn về cách xin một cuốn hộ chiếu.

Một đặc điểm giúp GOV.UK khác biệt so với một dự án chính phủ điển hình là nó được phát triển gần như hoàn toàn trong nội bộ, bởi chính các công chức làm việc cho cơ quan mới thành lập là Dịch vụ Kỹ thuật số của Chính phủ Anh (GDS), trực thuộc Văn phòng Nội các Anh. Nó cũng được xây dựng bằng phương pháp lặp, chi phí thấp và sử dụng các phương pháp và công nghệ linh hoạt gắn với các doanh nghiệp khởi nghiệp hơn là với các tổ chức lớn. Dưới đây là phần mô tả về cách thực hiện tiến trình này.

Kiểm thử Alpha và Beta

Cho đến cuối năm 2013, nhóm vận hành GOV.UK đã có hơn 100 người – nhưng nó không khởi đầu theo cách đó. Thực vậy, phiên bản đầu tiên không được gọi là GOV.UK. Một phiên bản Alpha được xây dựng bởi 14 người làm việc trong một căn phòng nhỏ thuộc tòa nhà chính phủ lớn, mục đích không phải là để trở thành một sản phẩm hoàn chỉnh mà chỉ cung cấp hình ảnh mô tả sơ lược về những đặc điểm của một trang web chính phủ duy nhất và cách xây dựng nó một cách nhanh chóng và rẻ tiền. Tổng cộng, giai đoạn Alpha kéo dài 12 tuần và chi phí 261.000 bảng Anh.

Những phản hồi từ người dùng của Alpha đã thúc đẩy việc ra đời phiên bản Beta, bản chất là mở rộng quy mô của nền tảng Alpha và thu hút sự tham gia của nhiều công chức chính phủ hơn. Lần đầu tiên phiên bản Beta được phát hành là 6 tháng sau khi phiên bản Alpha được lưu hành (bao gồm cả thời gian thành lập nhóm). Phiên bản Beta phát hành công khai đầu tiên đã chính thức là trang web của Chính phủ, tuy nhiên vào thời điểm đó, nó thiếu tất cả nội dung và tính năng cần thiết để thay thế các trang web chính đang sử dụng của Chính phủ. Sau tám tháng liên tục thực hiện các vòng lặp, với số lượng thành viên của nhóm lên đến 140 người và các nội dung và tính năng mới được bổ sung hằng ngày, lưu lượng truy cập đã chuyển hướng từ hai trong số các trang web chính phủ lớn nhất sang trang GOV.UK.

Việc làm này đã đem lại thành công. Trong năm tài khóa 2012-2013, GDS đã tiết kiệm được 42 triệu bảng Anh nhờ thay thế các trang web Directgov và BusinessLink bằng trang GOV.UK. Trong năm 2013-2014, ước tính GDS sẽ tiết kiệm được 50 triệu bảng Anh bằng cách đóng lại nhiều trang web khác và đưa chúng vào một tên miền duy nhất.

Các nhóm đa kỹ năng

Dịch vụ kỹ thuật số của chính phủ bao gồm các chuyên gia về phát triển phần mềm, quản lý sản phẩm, thiết kế, nghiên cứu người dùng, vận hành trang web, thiết kế nội dung, hoạch định chính sách và nhiều lĩnh vực cụ thể khác. Từ các chuyên gia này, chính phủ thành lập các nhóm để xây dựng và điều hành GOV.UK. Tuy nhiên, các nhóm đó không tập trung vào chuyên ngành hẹp mà phần lớn là các nhóm đa kỹ năng gồm những người sở hữu tổng hợp các kỹ năng cần thiết để thực hiện các nhiệm vụ được giao.

Ví dụ, nhóm làm việc vào các giai đoạn đầu của phiên bản Beta của GOV.UK gồm 7 lập trình viên, 2 nhà thiết kế, 1 người quản lý sản phẩm, 2 giám đốc phân phối và 5 nhà thiết kế nội dung. Ngay cả trong các lĩnh vực này cũng tồn tại nhiều kỹ năng khác nhau. Các lập trình viên có nhiều kỹ năng, từ kỹ thuật đầu vào đến quản lý hệ thống.

Bằng cách sử dụng các nhóm đa kỹ năng, có thể chuyển toàn bộ trách nhiệm về sản phẩm hoặc các nhiệm vụ cá nhân cho nhóm, loại bỏ nhu cầu về chỉ huy và kiểm soát quy mô lớn. Các nhóm nhỏ khép kín như thế ít phụ thuộc vào các nhóm khác nên có thể triển khai hoạt động nhanh hơn rất nhiều.

Mô hình đa kỹ năng này cũng giúp giảm thiểu các vấn đề thường thấy trong các tổ chức lớn có cấu trúc silo³. Ví dụ, Dịch vụ Kỹ thuật số của chính phủ đã phát triển theo thời gian, bổ sung các chuyên gia về bảo đảm an toàn thông tin Chính phủ, về mua sắm và quản lý IT nhằm tránh tình trạng tắc nghẽn và cải thiện việc sắp xếp ưu tiên các nguồn lực.

3 Cấu trúc silo là cấu trúc phân liên kết vòng và không có đường cụt, các liên kết phải tuần tự và không có sự chồng chéo và thường tạo thành một vòng tròn đơn khép. (ND)

Phân phối liên tục

Một khía cạnh quan trọng đóng góp vào thành công của GOV.UK là sự cải tiến liên tục dựa trên phản hồi của người dùng, kiểm thử và dữ liệu phân tích trang web. Nhóm GOV.UK phát hành phần mềm mới trung bình khoảng sáu lần mỗi ngày với tất cả các loại nâng cấp, từ các bản vá lỗi nhỏ đến các tính năng mới hoàn toàn cho các trang web và các nền tảng hỗ trợ.

Sau khi phiên bản Beta của GOV.UK ra mắt, một trong những nhà quản lý sản phẩm, với những kí ức xấu về việc phát hành phần mềm ở các tổ chức khác, đã thắc mắc liệu cơ chế triển khai phần mềm có thực sự hiệu quả không. Câu trả lời là “có”: tại thời điểm đó, GDS đã thực hiện hơn 1.000 đợt triển khai, do đó, đã khẳng định có độ tin cậy cao. Tự động triển khai liên tục làm nên sự hoàn hảo.

Tốc độ phát hành này không phải là phổ biến ở các tổ chức lớn, nơi mà đôi khi các quy trình hiện tại thậm chí còn chống lại mọi sự thay đổi. Các nhóm phát triển làm việc cho GOV.UK đã làm việc rất tích cực về tự động hóa, và họ đã có nhiều cuộc nói chuyện sâu sắc với những người quan tâm đến sự thay đổi nhanh chóng như thế. Danh từ chính được đề cập đến khi thảo luận về cách tiếp cận này là rủi ro, đặc biệt là việc làm thế nào để các bản phát hành đều đặn có thể quản lý và giảm thiểu những rủi ro của sự thay đổi.

Nhiều người không giỏi thực hiện các nhiệm vụ lặp nhưng các máy tính thì rất hoàn hảo trong tự động hóa các nhiệm vụ này. Việc triển khai phần mềm, đặc biệt nếu bạn định thực hiện một việc thường xuyên, là một yếu tố tuyệt vời cho quá trình tự động hóa. Nhờ sự phát triển và vận hành của GOV.UK, kết quả còn tuyệt vời hơn thế: việc cung cấp các máy ảo, cấu hình mạng, các quy tắc tường lửa và cấu hình hạ tầng đều được tự động hóa. Bằng cách viết dưới dạng mã các bộ phận chính của toàn bộ hệ thống, các lập trình viên đã sử dụng các công cụ như kiểm soát phiên bản và kiểm thử cục bộ để tạo sự tin tưởng vào những thay đổi của mình và tập trung vào một nhóm ít các quy trình đã được thực hiện thành thạo thay vì một quy trình riêng biệt (và các kỹ năng chuyên gia cần thiết) đối với mỗi loại thay đổi.

Các kỹ thuật khác cũng rất hữu ích. Sự tập trung không ngừng nghỉ vào người dùng và một nền văn hóa tin cậy từ chính ban lãnh đạo cấp cao của tổ chức đã đặt GDS vào tâm thế sử dụng rất nhiều những kiến thức học hỏi được để xây dựng và vận hành GOV.UK và sử dụng điều đó để chuyển đổi phần còn lại của Chính phủ Anh.

Cách tiếp cận của GDS đã được tất cả các cơ quan của chính phủ Anh chấp thuận và đem lại những thay đổi có lợi cho công dân. Xin trích dẫn một ví dụ, Nhóm Kỹ thuật số thuộc Bộ Tư pháp Anh mới đây đã làm việc với Cục Quản lý Tội phạm Quốc gia và Cơ sở Nhà tù Cải huấn để thay đổi thủ tục đăng ký thăm tù nhân. Trước đây, người thăm phải xin các mẫu được gửi đến qua đường bưu điện và sau đó gọi điện thoại đăng ký. Các yêu cầu này thường bị từ chối bởi vì đã kín lịch, buộc mọi người phải đăng ký lại. Bây giờ, các cuộc thăm thân nhân ở nhà tù có thể được đặt trực tuyến trong 5 phút, có thể lựa chọn đến 3 cuộc hẹn.

Không phải ai cũng vui thích với ý tưởng về việc chính phủ phát triển các khả năng IT riêng. Tim Gregory, vị chủ tịch người Anh của công ty CGI, nhà thầu lớn nhất cho trang web HealthCare.gov của Mỹ đã nhận được hợp đồng trị giá 292 triệu đô-la cho đến năm 2013 trước khi bị công ty Accenture thay thế vào tháng 01 năm 2014, tranh luận rằng cách tiếp cận GDS sẽ không có lợi cho các nhà cung cấp ở bên ngoài khi đấu giá các dự án của Chính phủ. Giám đốc Điều hành GDS Mike Bracken mô tả quan điểm này của Gregory là “hơn cả sự chế nhạo”.

Có thể rút ra một số nhận định sau khi nghiên cứu trường hợp GDS. Thứ nhất, khởi đầu nhỏ với một nhóm liên chức năng và từng bước phát triển năng lực của sản phẩm, đồng thời cung cấp các giá trị liên tục và tăng dần, là một phương pháp cực kỳ hiệu quả giúp giảm thiểu những rủi ro của các hệ thống có tầm nhìn xa, đồng thời phát triển một nền văn hóa hiệu năng cao. Nó mang lại lợi tức đầu tư nhanh hơn, tiết kiệm chi phí đáng kể và giúp nhân viên cũng như người dùng hạnh phúc hơn. Việc này khả thi, ngay cả trong một môi trường phức tạp và bị kiểm soát chặt chẽ như Chính phủ Anh.

Thứ hai, thay vì cố gắng thay thế các hệ thống và quy trình hiện tại bằng một “vụ nổ lớn”, GDS thay thế chúng dần dần, bắt đầu từ những điểm có thể cung cấp giá trị nhanh nhất. Họ áp dụng cấu trúc “ứng dụng sống bám” được trình bày trong Chương 10 và sử dụng nó để đem lại sự thay đổi cả về kiếntrúc và tổ chức.

Thứ ba, GDS theo đuổi phương pháp quản lý dựa trên nguyên tắc. Nhóm lãnh đạo ở GDS không nói cho từng nhân viên biết phải làm gì mà chỉ cung cấp một bộ nguyên tắc định hướng để mọi người đưa ra các quyết định phù hợp với các mục tiêu của tổ chức.

Các nguyên tắc quản lý GDS bao gồm:

1. Không làm chậm tốc độ phân phối.

2. Đưa ra quyết định, khi cần thiết và ở đúng cấp độ.

3. Dùng đúng người để triển khai.

4. Đích thân mục sở thị mọi việc.

5. Chỉ thực hiện việc đó nếu nó làm gia tăng giá trị.

6. Tin tưởng và thẩm tra.

Mọi người được tin tưởng là sẽ luôn đưa ra các quyết định hợp lý nhất trong hoàn cảnh của mình nhưng phải chịu trách nhiệm về những quyết định đó – cả về kết quả đạt được và việc nhận biết khi nào thì thích hợp để thu hút thêm người khác.

Cuối cùng, GDS cho thấy rằng mức khen thưởng cao bất thường và áp dụng một mô hình khu vực tư nhân không phải là nhân tố quyết định việc hình thành một nền văn hóa đổi mới. Nhân viên GDS là các công chức chứ không phải là các doanh nhân nắm quyền mua cổ phiếu ở Thung lũng Silicon. Một nền văn hóa đổi mới được tạo ra bằng cách khai thác nhu cầu của con người về khả năng làm chủ, sự tự chủ và theo đuổi mục đích – và đảm bảo rằng mọi người đều kiên định với mục đích của tổ chức và người dùng mà họ phục vụ.

HÃY BẮT ĐẦU HÀNH TRÌNH CỦA BẠN

Hãy khởi động bằng việc áp dụng các nguyên tắc sau:

Đảm bảo rằng hướng đi của bạn đã được xác định rõ ràng

Hướng đi này nên thể hiện ngắn gọn về hoạt động kinh doanh hoặc mô tả các kết quả tổ chức mà bạn muốn đạt được bằng các thuật ngữ có thể đo lường, ngay cả khi chúng có vẻ giống như một điều không tưởng. Quan trọng nhất là hướng đi này phải truyền được cảm hứng cho mọi người trong tổ chức. Hãy nghĩ đến mục đích tăng năng suất gấp 10 lần của HP FutureSmart.

Xác định và giới hạn phạm vi ban đầu

Đừng cố gắng thay đổi toàn bộ tổ chức. Hãy chọn một bộ phận nhỏ của tổ chức – những người có chung tầm nhìn với bạn và có khả năng theo đuổi nó. Giống như GDS, hãy bắt đầu bằng một nhóm liên chức năng duy nhất, có thể là một sản phẩm hoặc dịch vụ duy nhất. Hãy đảm bảo rằng bạn nhận được sự ủng hộ của tất cả các cấp từ ban điều hành trở xuống và từ các công nhân trở lên. Đưa ra các mục tiêu, nhưng đừng nghĩ quá nhiều về chúng hay lên kế hoạch để đạt được chúng. Hãy đảm bảo rằng nhóm có những gì cần thiết cho việc kiểm thử theo phương pháp Kata Cải tiến và tiếp tục tái lặp.

Theo đuổi nền văn hóa cải tiến liên tục hiệu năng cao

Có lẽ kết quả quan trọng nhất của việc triển khai Kata Cải tiến là tạo ra một tổ chức có thói quen cải tiến liên tục.

Bắt đầu với đúng người

Những phương pháp làm việc mới lan tỏa ra toàn tổ chức tương tự như những đổi mới khác, như chúng tôi đã mô tả trong phần đầu của Chương 2. Điều then chốt là phải tìm được những người có tư duy phát triển (xem Chương 11) và cảm thấy thoải mái khi kiểm thử những ý tưởng mới. Khi bạn đã đạt được những kết quả tích cực, hãy chuyển cho những người tiếp nhận đầu tiên, sau đó là đa số đầu tiên. Phần còn lại là tương đối dễ dàng, bởi chẳng có điều gì mà nhóm đa số sau ghét hơn việc phải nằm trong nhóm thiểu số. Cách tiếp cận này có thể được áp dụng cho từng đường chân trời được mô tả trong Chương 2.

Tìm cách phân phối sớm những kết quả có giá trị và có thể đo lường được Mặc dù tiến trình thay đổi luôn kéo dài và không bao giờ kết thúc cả nhưng việc sớm chứng minh kết quả thật, như nhóm GDS đã làm, là điều rất quan trọng. Sau đó cứ tiếp tục làm như vậy để xây dựng động lực và tạo sự tín nhiệm. Trên thực tế, chiến lược Kata Cải tiến được thiết kế là để đạt được mục đích này, điều mà chúng tôi hy vọng sẽ làm cho nó trở nên hấp dẫn đối với các nhà quản lý, những người thường phải chứng minh kết quả một cách nhanh chóng và nhất quán với một ngân sách eo hẹp.

Khi bạn thực nghiệm và học hỏi, hãy chia sẻ những gì có ích và không có ích. Hãy tổ chức thường xuyên các chương trình giới thiệu, mời các bên liên quan chính trong tổ chức và nhóm tiếp nhận tiếp theo của bạn. Hãy tổ chức các buổi họp rút kinh nghiệm để đánh giá những gì bạn đã đạt được, cập nhật và làm sâu sắc hơn tầm nhìn của bạn. Lúc nào cũng vậy, hãy không ngừng tiến lên phía trước. Nỗi sợ hãi, tính bất trắc và sự bất an là những chất xúc tác của bạn trên con đường phát triển. Bạn có thể bắt đầu ngay lúc này bằng cách điền vào bản mẫu đơn giản chỉ có độ dài một trang như trong Hình 15-4 (xem Chương 11 để biết thêm chi tiết về các điều kiện mục tiêu). Để biết thêm về cách tạo ra sự thay đổi bền vững, đặc biệt khi không có sự ủng hộ của ban điều hành, chúng tôi khuyến nghị bạn tham khảo cuốn Fearless Change: Patterns for Introducing New Ideas (tạm dịch: Thay đổi không sợ hãi: Những mô hình giới thiệu các ý tưởng mới) của Mary Lynn Manns và Linda Rising.

Hình 15-4: Dự thảo kế hoạch thay đổi

KẾT LUẬN

Việc xây dựng một doanh nghiệp tinh gọn, vững chắc và có khả năng thích ứng nhanh chóng với các điều kiện thay đổi phải dựa vào văn hóa học hỏi thông qua thực nghiệm. Để nền văn hóa này phát triển, toàn bộ tổ chức phải hiểu rõ mục đích của nó và nỗ lực liên tục để hiểu được các điều kiện hiện tại, đặt ra các điều kiện mục tiêu ngắn hạn và cho phép mọi người thực nghiệm để đạt được chúng. Sau đó, chúng ta đánh giá lại các điều kiện hiện tại, cập nhật các điều kiện mục tiêu dựa trên những gì học hỏi được, và tiếp tục cuộc hành trình. Hành vi này phải trở thành thói quen và phổ biến. Đó là cách chúng ta hình thành tư duy đổi mới liên tục tập trung vào nâng cao hơn bao giờ hết các dịch vụ và chất lượng khách hàng với chi phí thấp chưa từng có.

Những nguyên tắc này là sợi dây kết nối tất cả các kết cấu khoa học lại. Cho dù bạn đang tìm kiếm mô hình kinh doanh tái lặp thông qua vòng lặp học hỏi Khởi nghiệp Tinh gọn, đang nỗ lực cải tiến sản phẩm thông qua nghiên cứu người dùng và Phân phối Liên tục, hay đang thúc đẩy cải thiện tiến trình và thay đổi tổ chức bằng các chu trình PDCA của Kata Cải tiến – thì tất cả đều dựa vào nỗ lực theo đuổi sự đổi mới một cách nghiêm túc và mạnh mẽ trong điều kiện bất trắc. Việc đặt những nguyên tắc tương tự vào trung tâm của tiến trình phát triển sản phẩm hiệu quả và tinh gọn cũng như là sự thay đổi văn hóa là nhận thức của các tác giả cuốn sách này, nhưng có lẽ là không cần phải ngạc nhiên gì cả. Trong cả hai trường hợp, chúng ta đều phải đối mặt với sự bất trắc và phải làm việc trong một hệ thống thích ứng phức tạp mà không thể tiên lượng phản ứng của nó đối với sự thay đổi. Cả hai tình huống này đều đòi hỏi phải có sự tiến bộ tái lặp và tăng dần, kết quả từ sức sáng tạo của con người dưới sự kiểm soát của phương pháp khoa học đó.

Các tổ chức phải liên tục xem lại câu hỏi: “Mục đích của chúng ta là gì và chúng ta tổ chức như thế nào để có thể thúc đẩy tiềm năng lâu dài của mình cũng như của khách hàng và nhân viên?” Công việc quan trọng nhất của các nhà lãnh đạo là theo đuổi nền văn hóa hiệu năng cao được mô tả trong cuốn sách này. Bằng cách này, chúng ta có thể phát triển thịnh vượng trong một môi trường không ngừng tiến bộ về thiết kế và công nghệ cùng3 những thay đổi về xã hội và kinh tế rộng lớn hơn.