Hãy tưởng tượng một buổi sáng bình thường tại một doanh nghiệp phân phối hàng hóa.
8 giờ 47 phút.
Một khách hàng đặt hàng.
Nhân viên bán hàng xác nhận đơn.
Hệ thống ghi nhận giao dịch.
Kho nhận yêu cầu chuẩn bị.
Kế toán kiểm tra điều kiện thanh toán.
Bộ phận vận chuyển bắt đầu lên kế hoạch giao hàng.
Mọi thứ có vẻ đang hoạt động rất tốt.
Cho đến khi một vài chi tiết nhỏ xuất hiện.
Sản phẩm khách đặt vừa hết tồn kho thực tế, nhưng số lượng trên hệ thống chưa được cập nhật.
Khách hàng có một khoản công nợ quá hạn, nhưng nhân viên bán hàng đang xem dữ liệu từ một báo cáo được xuất hôm qua.
Khách yêu cầu nhận hàng trong buổi sáng, nhưng tuyến giao hàng đã được lập trước khi đơn được xác nhận.
Và nhân viên vừa hứa miễn phí vận chuyển vì tin rằng đây là một khách hàng quan trọng.
Không ai cố tình làm sai.
Nhân viên bán hàng đang cố gắng giữ khách.
Kho đang xử lý những đơn hàng đã được xác nhận.
Kế toán đang bảo vệ rủi ro tài chính.
Vận chuyển đang tối ưu chi phí và công suất.
Mỗi bộ phận đều có mục tiêu hợp lý.
Mỗi người đều có những thông tin mà họ tin là chính xác.
Nhưng tổng thể lại tạo ra một giao dịch mà doanh nghiệp không chắc mình có thể thực hiện đúng như đã cam kết.
Vấn đề không đơn thuần nằm ở một thao tác.
Nó nằm ở việc năm con người đang đưa ra quyết định dựa trên năm phiên bản khác nhau của cùng một thực tế kinh doanh.
Và khi những quyết định ấy gặp nhau, sự hỗn loạn xuất hiện.
Thông thường, chúng ta sẽ gọi đó là vấn đề phối hợp.
Tôi không hoàn toàn đồng ý.
Bởi vì phối hợp chỉ có ý nghĩa khi các bên chia sẻ một cách hiểu đủ nhất quán về điều đang xảy ra, những ràng buộc đang tồn tại và những cam kết đã được đưa ra.
Nếu những điều đó không được xác định rõ, yêu cầu mọi người phối hợp tốt hơn chỉ là yêu cầu họ bù đắp cho những thiếu sót trong kiến trúc bằng khả năng giao tiếp và trí nhớ cá nhân.
Tôi muốn một cách tiếp cận khác.
Không phải làm sao để năm người liên tục trao đổi với nhau cho đến khi mọi thứ khớp lại.
Mà là:
Làm sao thiết kế một hệ thống khiến năm người có thể làm những công việc khác nhau, tại những thời điểm khác nhau, nhưng vẫn cùng thực thi một thực tế kinh doanh nhất quán?
Đó là lúc tôi bắt đầu nghĩ về khái niệm Business Operating System.
01. Một doanh nghiệp không thiếu phần mềm. Nó thiếu sự nhất quán.
Có một điều khá thú vị trong thời đại chuyển đổi số.
Chúng ta có rất nhiều phần mềm.
CRM quản lý khách hàng.
ERP quản lý nguồn lực.
WMS quản lý kho.
Hệ thống kế toán quản lý tài chính.
Phần mềm vận chuyển quản lý giao nhận.
HRM quản lý nhân sự.
Dashboard theo dõi hiệu suất.
Và gần đây, AI xuất hiện để giúp mọi thứ trở nên thông minh hơn.
Trên lý thuyết, một doanh nghiệp sử dụng đầy đủ những công cụ đó đáng lẽ phải vận hành cực kỳ hiệu quả.
Nhưng thực tế không nhất thiết như vậy.
Một công ty có thể sở hữu rất nhiều phần mềm mà vẫn phụ thuộc vào những cuộc điện thoại để xác nhận thông tin.
Dữ liệu có thể tồn tại ở nhiều nơi nhưng không nơi nào thực sự có đủ thẩm quyền để xác định đâu là trạng thái đúng.
Một chính sách có thể được định nghĩa trong tài liệu, nhưng không được thực thi nhất quán trong giao dịch.
Một nhân viên có thể biết mình phải chịu trách nhiệm về kết quả, nhưng không có quyền quyết định những yếu tố ảnh hưởng đến kết quả đó.
Và một người quản lý có thể sở hữu rất nhiều báo cáo mà vẫn phải trực tiếp tham gia để xử lý những vấn đề đã xảy ra hàng trăm lần.
Tại sao?
Bởi vì số lượng phần mềm không đồng nghĩa với mức độ trưởng thành của kiến trúc vận hành.
Một CRM biết khách hàng là ai chưa chắc hiểu những cam kết thương mại đang ràng buộc doanh nghiệp với khách hàng đó.
Một ERP ghi nhận đơn hàng chưa chắc phản ánh đầy đủ cách doanh nghiệp quyết định có nên chấp nhận đơn hàng hay không.
Một dashboard có thể cho biết bao nhiêu đơn đã được giao, nhưng không giải thích được tại sao những đơn giao trễ lại liên tục xuất hiện ở cùng một điểm giao tiếp giữa bán hàng và vận chuyển.
Và một hệ thống AI có thể đưa ra những câu trả lời nghe rất thông minh mà không thực sự có quyền hoặc đủ thông tin để biến chúng thành hành động hợp lệ.
Tôi không cho rằng những phần mềm đó vô dụng.
Chúng giải quyết những nhóm vấn đề quan trọng.
Nhưng chúng không tự động tạo ra một kiến trúc thống nhất chỉ vì chúng được triển khai trong cùng một doanh nghiệp.
Một tổ chức có thể mua năm hệ thống rất tốt.
Và kết quả là có năm hệ thống rất tốt không hiểu nhau.
Một thành tựu công nghệ đáng ghi nhận.
Không chắc là thành tựu kinh doanh.
Digitalization is not the same as operational coherence.
Số hóa không đồng nghĩa với nhất quán vận hành.
Và sự nhất quán mới là điều tôi thực sự quan tâm.
02. Business Operating System không phải một phần mềm khổng lồ.
Tôi xuất thân từ Software Engineering, nên khi sử dụng khái niệm Operating System, tôi hiểu nó có thể tạo ra một sự liên tưởng khá trực tiếp.
Một hệ điều hành máy tính quản lý tài nguyên, thực thi những cơ chế nền tảng, cung cấp các interface và cho phép nhiều ứng dụng cùng hoạt động trên một hạ tầng chung.
Tôi thấy đây là một phép ẩn dụ hữu ích.
Nhưng phải nhấn mạnh: doanh nghiệp không phải máy tính.
Con người không phải process.
Khách hàng không phải request.
Và một thị trường đang thay đổi không thể được điều khiển bằng vài dòng configuration.
Tuy nhiên, sự tương đồng về kiến trúc rất đáng suy nghĩ.
Một hệ điều hành tốt không cần hiểu mục đích kinh doanh của từng ứng dụng.
Nó cung cấp những năng lực nền tảng để ứng dụng có thể hoạt động mà không phải tự xây dựng mọi thứ từ đầu.
Một ứng dụng không cần tự phát minh cơ chế quản lý bộ nhớ.
Không cần tự viết lại toàn bộ hệ thống phân quyền truy cập tài nguyên.
Không cần tự thiết kế những cơ chế cơ bản để tương tác với các thành phần khác.
Nó sử dụng những interface được hệ điều hành cung cấp.
Trong doanh nghiệp, tôi muốn một điều tương tự.
Một nhóm kinh doanh mới không nên phải tự phát minh quy trình kiểm soát công nợ.
Một nhân viên phát triển thị trường không nên phải tự thiết kế cách xác minh khách hàng đã thuộc về một người phụ trách khác hay chưa.
Một công cụ bán hàng mới không nên phải tự xây dựng logic giá, quyền hạn và điều kiện giao dịch từ đầu.
Và một bộ phận muốn thử nghiệm phương pháp vận hành mới không nên phải tạo ra một nguồn dữ liệu riêng, không liên kết với thực tế chung của doanh nghiệp.
Những năng lực nền tảng cần được cung cấp bởi một kiến trúc có thể tái sử dụng.
Tôi gọi đó là Business Operating System.
Không phải một phần mềm duy nhất.
Mà là một kiến trúc kết nối những thành phần quan trọng của hoạt động doanh nghiệp.
Dữ liệu.
Quy tắc.
Quyền hạn.
Quy trình.
Giao diện.
Con người.
Và những cơ chế học hỏi từ kết quả.
Một ERP có thể là thành phần quan trọng trong kiến trúc đó.
Một CRM cũng vậy.
Nhưng không có lý do gì để mặc định một sản phẩm phần mềm phải sở hữu toàn bộ logic kinh doanh của doanh nghiệp.
The Business Operating System is not the collection of applications. It is the architecture that makes those applications, decisions and people work coherently together.
Điều quan trọng không phải chúng ta đang dùng bao nhiêu phần mềm.
Mà là chúng có cùng tham gia thực thi một hệ thống kinh doanh nhất quán hay không.
03. Tầng nền tảng: Doanh nghiệp phải biết điều gì là thật.
Hãy bắt đầu từ dữ liệu.
Một khách hàng là ai?
Một sản phẩm là gì?
Một đơn hàng có trạng thái nào?
Một khoản công nợ được xác định ra sao?
Một cam kết giao hàng được tạo ra khi nào?
Những câu hỏi nghe rất cơ bản.
Nhưng khi doanh nghiệp phát triển, chúng thường trở nên phức tạp hơn nhiều so với tưởng tượng ban đầu.
Một khách hàng có thể xuất hiện dưới nhiều số điện thoại.
Một doanh nghiệp có thể có nhiều người đặt hàng.
Một người mua có thể đại diện cho nhiều cửa hàng.
Một sản phẩm có thể tồn tại dưới nhiều quy cách đóng gói.
Một giá bán có thể phụ thuộc vào loại khách hàng, số lượng mua, thời điểm và những điều kiện thương mại khác.
Và một đơn hàng có thể trải qua nhiều trạng thái mà mỗi bộ phận sử dụng một cách diễn giải khác nhau.
Nếu không thống nhất được những khái niệm đó, chúng ta rất khó xây dựng những quyết định có chất lượng.
Tôi thích bắt đầu từ Business Identity.
Mỗi thực thể quan trọng cần có một định danh rõ ràng.
Khách hàng.
Sản phẩm.
Đơn hàng.
Đơn vị vận chuyển.
Nhân viên.
Chính sách.
Và những quan hệ giữa chúng.
Nhưng định danh chỉ là bước đầu.
Một mã khách hàng không tự động giải thích được khách hàng đó có quan hệ thế nào với những cửa hàng, người mua hoặc tài khoản khác.
Một mã sản phẩm không tự động mô tả đầy đủ thuộc tính vật lý, quy cách thương mại và khả năng tương thích của nó với sản phẩm khác.
Một trạng thái đơn hàng không có nhiều ý nghĩa nếu các bộ phận đang sử dụng cùng một từ để mô tả những điều khác nhau.
Ví dụ, đơn hàng được đánh dấu là "Đã xác nhận".
Xác nhận điều gì?
Khách hàng đã đồng ý mua?
Hàng hóa đã được giữ tồn?
Điều kiện thanh toán đã được thông qua?
Hay doanh nghiệp đã chính thức cam kết thực hiện giao dịch?
Nếu hệ thống không phân biệt, cùng một trạng thái có thể tạo ra những giả định hoàn toàn khác nhau giữa các bộ phận.
Đó là nơi những vấn đề bắt đầu xuất hiện.
Một hệ thống không thể đưa ra quyết định đáng tin cậy nếu chính những khái niệm mà nó sử dụng chưa được định nghĩa đủ chính xác.
Vì vậy, Business Operating System cần một mô hình dữ liệu phản ánh thực tế kinh doanh.
Không nhất thiết phải lưu mọi thông tin trong một database duy nhất.
Một hệ thống kế toán có thể là nguồn dữ liệu có thẩm quyền về công nợ.
Một hệ thống kho có thể chịu trách nhiệm về trạng thái tồn và giữ hàng.
Một CRM có thể chịu trách nhiệm về quan hệ khách hàng và người phụ trách.
Điều cần thống nhất là mỗi sự thật quan trọng được xác định ở đâu, có ý nghĩa gì và các thành phần khác sử dụng nó như thế nào.
Một nguồn sự thật có thẩm quyền không đồng nghĩa với một cơ sở dữ liệu khổng lồ.
Nó đồng nghĩa với việc không có hai hệ thống cùng tự nhận mình là người quyết định cuối cùng về cùng một trạng thái mà không có cơ chế giải quyết sự khác biệt.
One business reality. Multiple specialized representations. Clear ownership of truth.
Đây là nền móng.
Nếu tầng dữ liệu không đáng tin cậy, mọi thứ được xây bên trên chỉ có thể đáng tin cậy đến mức dữ liệu cho phép.
Kể cả AI.
Đặc biệt là AI.
Bởi vì một hệ thống AI có thể biến dữ liệu sai thành một lời giải thích rất thuyết phục.
Và đôi khi, đó còn nguy hiểm hơn một màn hình hiển thị lỗi rõ ràng.
04. Dữ liệu không chỉ cần đúng. Nó cần có ngữ nghĩa.
Tôi muốn đi sâu thêm một chút.
Trong một doanh nghiệp phân phối bao bì, chúng ta có thể có hàng nghìn sản phẩm.
Ly nhựa.
Nắp ly.
Ống hút.
Tô giấy.
Hộp đựng thực phẩm.
Túi giấy.
Mỗi sản phẩm có nhiều thuộc tính.
Dung tích.
Đường kính.
Chất liệu.
Quy cách đóng gói.
Thương hiệu.
Mục đích sử dụng.
Và các quan hệ với những sản phẩm khác.
Nếu dữ liệu chỉ được tổ chức như một bảng danh sách hàng hóa, chúng ta có thể thực hiện tốt việc tìm kiếm theo tên hoặc mã.
Nhưng khi cần tư vấn một bộ sản phẩm phù hợp, vấn đề trở nên khác.
Khách hàng mua một loại ly.
Hệ thống có thể đề xuất nắp nào?
Đề xuất dựa trên đường kính danh nghĩa, loại vành miệng, quan hệ tương thích đã được kiểm chứng hay chỉ dựa trên những giao dịch từng mua cùng nhau?
Nếu một sản phẩm có dung tích 700ml, điều đó có nghĩa nó luôn phù hợp với cùng một loại nắp như một sản phẩm 700ml khác?
Không.
Nếu hai sản phẩm thường được mua cùng nhau, điều đó có chứng minh chúng tương thích về mặt kỹ thuật?
Cũng không.
Một mô hình dữ liệu tốt phải phân biệt thuộc tính, quan hệ và mức độ tin cậy của những quan hệ đó.
Đây là nơi tôi quan tâm đến Semantic Modeling.
Không chỉ lưu trữ dữ liệu.
Mà xác định ý nghĩa của dữ liệu và mối quan hệ giữa các thực thể.
Một sản phẩm có thể thuộc một danh mục.
Có thể tương thích với một nhóm phụ kiện.
Có thể được sử dụng trong một công thức đồ uống.
Có thể phục vụ một phân khúc khách hàng.
Và có thể có những ràng buộc về kỹ thuật in ấn hoặc phương pháp sử dụng.
Khi những quan hệ đó được biểu diễn đủ rõ, hệ thống không chỉ biết mình đang sở hữu những sản phẩm gì.
Nó bắt đầu có khả năng hỗ trợ trả lời những câu hỏi kinh doanh phức tạp hơn.
Một cửa hàng mới kinh doanh loại đồ uống này nên lựa chọn những nhóm bao bì nào?
Nếu thay đổi loại ly, những thành phần khác của bộ sản phẩm có còn phù hợp không?
Nếu một sản phẩm tạm hết hàng, phương án thay thế nào đáp ứng những điều kiện cần thiết?
Nếu khách muốn in logo, những loại sản phẩm nào hỗ trợ phương pháp in phù hợp với yêu cầu?
Điều thú vị là khi dữ liệu được tổ chức theo ngữ nghĩa, nhiều năng lực có thể sử dụng chung một nền tảng tri thức.
Tìm kiếm.
Tư vấn.
Gợi ý sản phẩm.
Cross-sell.
Xây dựng bộ sưu tập.
Hỗ trợ AI.
Và cả những công cụ dành cho nhân viên.
Nhưng điều đó không có nghĩa mọi quan hệ đều phải được mô hình hóa ngay từ đầu.
Một mô hình quá tham vọng có thể trở thành gánh nặng bảo trì.
Tôi muốn bắt đầu từ những quan hệ tạo ra giá trị thực tế, có thể kiểm chứng và có khả năng được tái sử dụng.
Semantic structure is valuable when it improves decisions, not merely when it makes the data model look sophisticated.
Một mô hình tri thức không nên tồn tại chỉ để người thiết kế tự hào rằng mình đã xây dựng được một graph rất đẹp.
Nó phải giúp một người nào đó làm việc tốt hơn.
Hoặc giúp hệ thống giải quyết được một vấn đề mà trước đó nó chưa thể giải quyết.
Nếu không, chúng ta chỉ vừa tạo ra một cách lưu trữ dữ liệu phức tạp hơn.
Với rất nhiều node và edge.
Khá thú vị về mặt kỹ thuật.
Không chắc thú vị lắm với bộ phận kế toán.
05. Dữ liệu phải kết nối với quyết định.
Một doanh nghiệp có dữ liệu chính xác chưa chắc đưa ra quyết định tốt.
Chúng ta còn cần những nguyên tắc xác định dữ liệu đó được sử dụng như thế nào.
Hãy quay lại với một đơn hàng.
Khách hàng chọn sản phẩm.
Hệ thống biết giá.
Biết tồn kho.
Biết điều kiện thanh toán.
Biết khu vực giao hàng.
Biết lịch sử giao dịch.
Nhưng biết những thông tin đó chưa đủ để quyết định có nên chấp nhận đơn hàng hay không.
Chúng ta còn cần những quy tắc kinh doanh.
Khách hàng có đủ điều kiện giao dịch?
Giá bán có phù hợp với chính sách?
Tồn kho có khả năng đáp ứng?
Phí vận chuyển được xác định thế nào?
Cam kết giao hàng có khả thi?
Những ngoại lệ nào được phép?
Và ai có thẩm quyền chấp thuận?
Đây là tầng tôi gọi là Business Decision Architecture.
Nó kết nối dữ liệu với hành động thông qua những chính sách và ràng buộc có thể thực thi.
Một điều tôi đặc biệt quan tâm là tránh để cùng một chính sách được triển khai độc lập tại quá nhiều nơi.
Nếu nhân viên bán hàng tính giá theo một logic, website tính giá theo một logic khác, còn hệ thống xử lý đơn sử dụng một phiên bản chính sách cũ, chúng ta sẽ sớm có những giao dịch không nhất quán.
Và nếu mỗi bộ phận tự tạo cơ chế kiểm tra điều kiện giao dịch, những thay đổi chính sách có thể không được áp dụng đồng bộ.
Tôi muốn các quyết định quan trọng sử dụng những năng lực có thẩm quyền được xác định rõ.
Không có nghĩa toàn bộ logic phải nằm trong một service duy nhất.
Nhưng phải có một mô hình nhất quán về nơi những quy tắc được định nghĩa và thực thi.
Đặc biệt, có một nguyên tắc rất quan trọng:
Một quyết định hợp lệ tại thời điểm đề xuất chưa chắc còn hợp lệ tại thời điểm thực thi.
Hãy tưởng tượng hệ thống kiểm tra tồn kho và xác nhận rằng có đủ hàng.
Hai phút sau, trước khi đơn được hoàn tất, một giao dịch khác sử dụng phần tồn kho đó.
Nếu hệ thống chỉ kiểm tra điều kiện ban đầu mà không bảo đảm tính nhất quán khi cam kết giao dịch, chúng ta vẫn có thể tạo ra những đơn hàng không thể đáp ứng.
Tương tự, một khách hàng có thể đủ hạn mức công nợ khi nhân viên bắt đầu tạo đơn, nhưng điều kiện đã thay đổi trước lúc xác nhận.
Vì vậy, kiểm soát không chỉ là hiển thị cảnh báo.
Nó phải được đặt tại những điểm mà quyết định thực sự tạo ra cam kết.
Tùy loại nghiệp vụ, điều này có thể cần cơ chế giữ tồn, kiểm tra phiên bản trạng thái, thực thi giao dịch hoặc những phương thức bảo đảm nhất quán phù hợp.
Tôi không cho rằng tất cả đều cần một giải pháp kỹ thuật giống nhau.
Nhưng về mặt nguyên lý, tôi muốn một điều rõ ràng:
The system must enforce important constraints at the point where they matter.
Một cảnh báo đẹp không thay thế được một cơ chế kiểm soát đáng tin cậy.
Và một nút bấm màu đỏ với dòng chữ "Vui lòng chú ý" cũng không có khả năng tự bảo vệ lợi nhuận.
Dù designer có dành cả ngày để chọn đúng sắc đỏ.
06. Quyền hạn là một phần của kiến trúc, không phải phụ lục của HR.
Một hệ thống có thể biết chính xác điều kiện giao dịch.
Nhưng vẫn cần biết ai có quyền làm gì.
Ai được tạo đơn?
Ai được điều chỉnh giá?
Ai được cấp ưu đãi?
Ai được chấp thuận công nợ?
Ai được thay đổi người phụ trách khách hàng?
Ai được sửa một chính sách?
Và ai được triển khai một thay đổi ảnh hưởng đến hoạt động production?
Những câu hỏi này thường được xử lý thông qua chức danh hoặc danh sách quyền truy cập phần mềm.
Tôi nghĩ như vậy chưa đủ.
Quyền truy cập một chức năng và quyền đưa ra một quyết định kinh doanh không hoàn toàn giống nhau.
Một nhân viên có thể được mở màn hình điều chỉnh giá nhưng chỉ được phép thay đổi trong những điều kiện nhất định.
Một người quản lý có thể có quyền phê duyệt một nhóm ngoại lệ nhưng không được thay đổi chính sách nền tảng.
Một nhân viên có thể sở hữu quan hệ chăm sóc khách hàng nhưng không có quyền thay đổi công nợ hay chuyển quyền sở hữu khách hàng tùy ý.
Tôi muốn những quyền hạn đó được mô hình hóa như một phần của kiến trúc vận hành.
Không chỉ dựa vào tên chức danh.
Mà dựa trên vai trò, phạm vi trách nhiệm, điều kiện, mức độ rủi ro và những cơ chế ủy quyền hợp lệ.
Một quyết định có thể được phân quyền trong phạm vi nhất định.
Vượt khỏi phạm vi đó, nó phải đi qua một đường xử lý ngoại lệ.
Và khi quyết định được thực hiện, hệ thống cần biết ai đã quyết định, dựa trên chính sách nào, với những thông tin gì.
Điều này có giá trị vượt khỏi việc kiểm tra trách nhiệm.
Nó giúp tổ chức học hỏi.
Chúng ta có thể phân tích những quyết định nào thường xuyên cần phê duyệt.
Những loại ngoại lệ nào có thể được phân quyền thêm.
Những ràng buộc nào đang tạo ra độ trễ không cần thiết.
Và những nhóm nhân sự nào đã phát triển đủ năng lực để nhận trách nhiệm lớn hơn.
Quyền hạn không nên chỉ được lưu trong sơ đồ tổ chức. Nó phải tồn tại trong cách công việc thực sự được thực thi.
Nếu một nhân viên được tuyên bố là có quyền tự chủ nhưng phần mềm vẫn buộc họ phải hỏi quản lý cho mọi quyết định, quyền tự chủ đó chỉ tồn tại trên giấy.
Ngược lại, nếu hệ thống cho phép một nhân viên thực hiện những hành động vượt khỏi thẩm quyền đã được xác định, tổ chức đang phụ thuộc vào sự tự giác để bảo vệ những ràng buộc quan trọng.
Tôi không thích cả hai.
Một bên giết chết năng lực.
Bên còn lại tạo ra rủi ro.
Kiến trúc tốt phải biết phân biệt.
07. Workflow không phải một chuỗi nút bấm. Nó là vòng đời của cam kết.
Có một cách thiết kế phần mềm nghiệp vụ mà tôi thấy khá hạn chế.
Chúng ta quan sát những thao tác nhân viên đang làm.
Sau đó biến từng thao tác thành một chức năng.
Nhân viên tạo đơn.
Có nút tạo đơn.
Quản lý duyệt đơn.
Có nút phê duyệt.
Kho xác nhận hàng.
Có nút xác nhận.
Vận chuyển giao hàng.
Có nút hoàn tất.
Nhìn qua, doanh nghiệp đã được số hóa.
Nhưng chúng ta mới chỉ chuyển những hành động thủ công sang giao diện.
Điều quan trọng hơn là ý nghĩa của những trạng thái và cam kết mà các hành động đó tạo ra.
Một đơn hàng không chỉ là một bản ghi.
Nó đại diện cho một chuỗi cam kết giữa những bên liên quan.
Khách hàng cam kết mua trong những điều kiện nhất định.
Doanh nghiệp cam kết cung cấp hàng hóa.
Kho cam kết chuẩn bị.
Vận chuyển cam kết thực hiện giao nhận.
Và những điều kiện tài chính phải được đáp ứng ở những thời điểm phù hợp.
Mỗi cam kết có điều kiện hình thành, trạng thái thực hiện và phương thức xử lý khi không thể tiếp tục.
Đó là cách tôi thích nhìn nhận một workflow.
Không phải danh sách những nút bấm.
Mà là một state machine phản ánh vòng đời của các cam kết kinh doanh.
Một đơn hàng có thể được tạo nhưng chưa được chấp nhận.
Được chấp nhận nhưng chưa được giữ hàng.
Được giữ hàng nhưng chưa được bàn giao vận chuyển.
Được bàn giao nhưng chưa được giao thành công.
Và trong quá trình đó, nó có thể phát sinh yêu cầu thay đổi, hủy bỏ hoặc xử lý ngoại lệ.
Nếu những trạng thái không được định nghĩa rõ, các bộ phận sẽ tự diễn giải.
Nhân viên bán hàng cho rằng đơn đã xong vì khách đồng ý.
Kho cho rằng đơn chưa thể xử lý vì thiếu hàng.
Vận chuyển cho rằng chưa có cam kết giao vì đơn chưa được lên tuyến.
Kế toán cho rằng giao dịch không hợp lệ vì điều kiện thanh toán chưa được xác nhận.
Và khách hàng chỉ biết một điều.
Họ đã được hứa.
Một kiến trúc vận hành tốt phải kết nối những trạng thái đó thành một luồng có ý nghĩa chung.
Không phải mọi thao tác đều cần tự động hóa.
Nhưng các chuyển đổi trạng thái quan trọng cần có điều kiện rõ ràng.
Một cam kết không nên được tạo ra nếu những điều kiện bắt buộc chưa được đáp ứng.
Một trạng thái không nên được thay đổi chỉ vì một người có quyền truy cập database.
Và một ngoại lệ không nên âm thầm phá vỡ những ràng buộc mà các thành phần khác đang phụ thuộc.
A business workflow is a protocol for creating, fulfilling and resolving commitments.
Tôi thích định nghĩa này hơn rất nhiều so với việc xem workflow là chuỗi công việc cần hoàn thành.
Bởi vì nó buộc chúng ta đặt câu hỏi về trách nhiệm, điều kiện và kết quả.
Không chỉ về thao tác.
08. Một hệ thống thống nhất không có nghĩa mọi thứ phải chạy cùng một chỗ.
Khi nói đến Business Operating System, một người có nền tảng kỹ thuật có thể lập tức nghĩ đến kiến trúc phần mềm.
Monolith hay microservices?
Centralized hay distributed?
Synchronous hay asynchronous?
Event-driven hay request-response?
Tôi thấy những câu hỏi đó thú vị.
Nhưng tôi không nghĩ chúng nên là điểm khởi đầu.
Một doanh nghiệp có thể có kiến trúc microservices cực kỳ hiện đại mà vẫn vận hành hỗn loạn.
Và một doanh nghiệp sử dụng một hệ thống tương đối tập trung vẫn có thể vận hành rất tốt nếu những ranh giới nghiệp vụ được xác định đúng.
Vấn đề trước tiên không phải cách chúng ta chia code.
Mà là cách chúng ta chia trách nhiệm và những cam kết giữa các thành phần.
Nếu hệ thống kho thay đổi trạng thái tồn, những thành phần nào cần biết?
Nếu một đơn hàng được xác nhận, những hoạt động nào phải được kích hoạt?
Nếu khách hàng bị thay đổi điều kiện giao dịch, những quyết định đang chờ xử lý có cần được đánh giá lại không?
Nếu một bước thất bại, hệ thống sẽ dừng, thử lại hay chuyển sang xử lý thủ công?
Không phải mọi thông tin đều cần được đồng bộ ngay lập tức.
Nhưng chúng ta phải biết thông tin nào cần nhất quán ở thời điểm nào.
Một báo cáo phân tích có thể chấp nhận độ trễ.
Một gợi ý nội dung có thể sử dụng dữ liệu được cập nhật theo chu kỳ.
Nhưng một quyết định giữ tồn kho hoặc kiểm soát tín dụng có thể đòi hỏi những bảo đảm chặt chẽ hơn.
Tôi muốn kiến trúc phản ánh sự khác biệt đó.
Có những hoạt động phù hợp với xử lý đồng bộ.
Có những hoạt động phù hợp với sự kiện bất đồng bộ.
Có những kết quả có thể được tính toán lại.
Và có những cam kết không thể đơn giản hoàn tác sau khi đã ảnh hưởng đến thế giới thực.
Nếu một hệ thống gửi lại cùng một sự kiện hai lần, chúng ta không muốn vô tình tạo ra hai đơn hàng.
Nếu một tiến trình xử lý thất bại giữa chừng, chúng ta cần biết trạng thái nào đã thực sự được cam kết.
Nếu một bộ phận tạm thời không truy cập được hệ thống, doanh nghiệp phải xác định những hoạt động nào được phép tiếp tục và những hoạt động nào cần dừng lại để bảo vệ rủi ro.
Đây là những vấn đề kỹ thuật.
Nhưng ý nghĩa của chúng là kinh doanh.
Technical architecture must reflect business consistency requirements, not merely engineering fashion.
Tôi không quan tâm chúng ta sử dụng kiến trúc nào chỉ để trông hiện đại hơn đối thủ.
Tôi quan tâm đến việc kiến trúc đó có giúp doanh nghiệp duy trì những cam kết quan trọng một cách đáng tin cậy hay không.
Và có thể thay đổi khi nhu cầu kinh doanh thay đổi hay không.
Một hệ thống rất hiện đại nhưng không phù hợp với hoạt động thực tế vẫn là một hệ thống tồi.
Chỉ là nó tốn nhiều tiền hơn để xây dựng.
09. Giao diện tốt phải làm giảm nhu cầu hiểu toàn bộ hệ thống.
Đây là điểm tôi nghĩ rất dễ bị bỏ qua khi những người có năng lực kỹ thuật mạnh thiết kế phần mềm cho tổ chức.
Người thiết kế có thể hiểu toàn bộ mô hình dữ liệu.
Hiểu các ràng buộc.
Hiểu trạng thái.
Hiểu quyền hạn.
Hiểu những trường hợp ngoại lệ.
Và hiểu vì sao mỗi thành phần được xây dựng theo cách hiện tại.
Nhưng người sử dụng không nhất thiết cần hiểu tất cả.
Một nhân viên bán hàng không cần trở thành chuyên gia về hệ thống kế toán để biết một giao dịch có được phép thực hiện hay không.
Một nhân viên kho không cần hiểu toàn bộ chính sách thương mại để biết đơn hàng nào cần chuẩn bị trước.
Một người phụ trách vận chuyển không cần đọc lịch sử trao đổi giữa khách và nhân viên bán hàng để xác định những cam kết giao hàng đã được chấp thuận.
Giao diện phải cung cấp đúng thông tin cần thiết tại thời điểm quyết định.
Không nhiều hơn một cách vô ích.
Và cũng không ít hơn mức cần thiết.
Tôi thích nguyên lý Progressive Disclosure.
Hiển thị những gì người dùng cần để thực hiện công việc hiện tại.
Cho phép họ truy cập sâu hơn khi cần.
Nhưng không bắt mọi người phải xử lý toàn bộ sự phức tạp của doanh nghiệp chỉ để hoàn thành một thao tác.
Một hệ thống tốt có thể rất phức tạp bên trong.
Nhưng trải nghiệm sử dụng không nhất thiết phải phức tạp tương ứng.
Đây là một trong những giá trị quan trọng nhất của abstraction.
Nó cho phép những thành phần phức tạp được biểu diễn thông qua những interface dễ hiểu và có ý nghĩa.
Ví dụ, thay vì yêu cầu nhân viên tự tính lợi nhuận sau vận chuyển, hệ thống có thể cung cấp trạng thái phù hợp với chính sách.
Thay vì yêu cầu người dùng tự kiểm tra hàng loạt điều kiện tín dụng, hệ thống có thể cho biết giao dịch được phép tiếp tục, cần bổ sung thông tin hay phải chuyển phê duyệt.
Thay vì yêu cầu nhân viên ghi nhớ hàng trăm mối quan hệ sản phẩm, hệ thống có thể hỗ trợ tìm những lựa chọn đã được xác minh phù hợp.
Nhưng giao diện cũng phải cho phép người dùng hiểu tại sao một quyết định bị chặn.
Một thông báo "Không được phép" mà không có lý do hợp lý có thể tạo ra sự bực bội.
Một cơ chế từ chối không có đường xử lý ngoại lệ có thể khiến hoạt động kinh doanh bị đình trệ.
Và một giao diện chỉ hiển thị kết luận mà không cho phép kiểm chứng dữ liệu quan trọng có thể khiến người dùng phụ thuộc mù quáng vào hệ thống.
Tôi muốn phần mềm giảm gánh nặng nhận thức.
Không phải thay thế toàn bộ năng lực phán đoán của con người.
Good UX is not simply making software easy to use. It is making the right business decisions easier to make.
Đây là một tiêu chuẩn khó hơn nhiều so với việc giao diện có đẹp hay không.
Một nút bấm có thể rất đẹp.
Nhưng nếu nó khiến người dùng dễ dàng tạo ra một quyết định kinh doanh sai, thiết kế đó chưa chắc đã tốt.
Và nếu một giao diện buộc nhân viên phải hiểu năm hệ thống khác nhau trước khi hoàn thành một công việc, chúng ta chưa thực sự giải quyết được vấn đề.
Chúng ta chỉ đem sự phức tạp của backend ra trưng bày ở frontend.
Một triển lãm kiến trúc.
Không ai mua vé.
Nhưng tất cả nhân viên đều bắt buộc phải tham quan mỗi ngày.
10. Business Operating System phải có khả năng quan sát chính nó.
Một hệ thống vận hành có thể hoạt động đúng theo thiết kế.
Nhưng điều gì bảo đảm rằng thiết kế đó đang tạo ra kết quả tốt?
Đây là nơi tôi nghĩ nhiều doanh nghiệp gặp một vấn đề nghiêm trọng.
Chúng ta triển khai quy trình.
Xác định KPI.
Xây dựng dashboard.
Theo dõi kết quả.
Nhưng không phải lúc nào những gì được đo lường cũng phản ánh điều chúng ta thực sự muốn cải thiện.
Một hệ thống phân bổ khách hàng có thể giảm thời gian phản hồi lead.
Tốt.
Nhưng chất lượng tư vấn có tăng không?
Một quy trình mới có thể tăng số lượng đơn hàng được xử lý mỗi ngày.
Tốt.
Nhưng giá trị kinh tế trung bình của mỗi đơn có thay đổi không?
Một cơ chế tự động hóa có thể giảm số lượng yêu cầu phê duyệt.
Tốt.
Nhưng tỷ lệ sai sót và tổn thất có tăng lên không?
Một chiến dịch marketing có thể tạo ra rất nhiều lead.
Tốt.
Nhưng bao nhiêu trong số đó trở thành khách hàng thực sự?
Và bao nhiêu tiếp tục quay lại sau giao dịch đầu tiên?
Tôi không thích những dashboard chỉ phản ánh hoạt động.
Tôi muốn chúng hỗ trợ đánh giá kết quả và chất lượng vận hành.
Điều này đòi hỏi một tầng Business Observability.
Không chỉ biết hệ thống có lỗi kỹ thuật hay không.
Mà biết những quyết định đang tạo ra kết quả gì.
Một quy tắc mới ảnh hưởng đến bao nhiêu giao dịch?
Tỷ lệ ngoại lệ thay đổi thế nào?
Thời gian chờ tại các bước phê duyệt ra sao?
Những giao dịch nào bị chặn và vì lý do gì?
Một cơ chế gợi ý sản phẩm có làm tăng khả năng mua đúng bộ sản phẩm hay không?
Một thay đổi chính sách giao hàng có ảnh hưởng đến tỷ lệ khách quay lại?
Đây là những câu hỏi quan trọng hơn số lượng request mà server xử lý mỗi giây, ít nhất khi chúng ta đang đánh giá kết quả kinh doanh.
Dĩ nhiên, hiệu suất kỹ thuật vẫn quan trọng.
Một hệ thống sập liên tục khó có thể tạo ra trải nghiệm vận hành tốt.
Nhưng hiệu suất kỹ thuật chỉ là một phần của câu chuyện.
A system can be technically healthy and economically dysfunctional.
Một hệ thống có thể hoạt động hoàn hảo về mặt kỹ thuật.
Và thất bại hoàn toàn về mặt kinh doanh.
Tôi muốn Business Operating System có khả năng quan sát cả hai.
Đặc biệt, khi một chỉ số thay đổi, chúng ta phải có đủ thông tin để xem xét nguyên nhân.
Nếu tỷ lệ giao trễ tăng, liệu vấn đề nằm ở kho, kế hoạch vận chuyển, chất lượng dữ liệu hay những cam kết không khả thi được tạo ra ở bước bán hàng?
Nếu số lượng đơn tăng nhưng lợi nhuận không tăng tương ứng, liệu hệ thống đang khuyến khích những loại giao dịch không hiệu quả?
Nếu khách hàng mới giảm nhưng doanh thu từ khách cũ tăng, liệu đó là tín hiệu tích cực hay một rủi ro phát triển thị trường?
Một dashboard không nên chỉ trả lời chuyện gì đã xảy ra.
Nó nên giúp tổ chức đặt ra những câu hỏi tốt hơn về nguyên nhân.
Và không được nhầm một sự tương quan đẹp với bằng chứng nhân quả.
11. Những ngoại lệ phải quay trở lại để thay đổi hệ thống.
Đến đây, chúng ta đã có những thành phần quan trọng.
Dữ liệu.
Quy tắc.
Quyền hạn.
Quy trình.
Giao diện.
Và khả năng quan sát kết quả.
Nhưng nếu dừng ở đó, chúng ta mới xây dựng một hệ thống có thể vận hành.
Chưa chắc đã có khả năng tiến hóa.
Một Business Operating System trưởng thành phải học được từ những gì xảy ra.
Hãy tưởng tượng một loại ngoại lệ liên tục xuất hiện.
Ban đầu, nó được chuyển đến người quản lý.
Người quản lý đưa ra quyết định.
Hệ thống ghi nhận lý do.
Sau một thời gian, chúng ta có đủ dữ liệu để nhận diện mẫu hình.
Những điều kiện nào thường dẫn đến việc chấp thuận?
Những trường hợp nào thường bị từ chối?
Kết quả kinh doanh của những quyết định đó ra sao?
Có thể chuyển một phần quyết định xuống cấp thấp hơn không?
Có thể thiết kế một quy tắc mới không?
Hay chính sách hiện tại đang không còn phù hợp?
Từ đó, tổ chức có thể thay đổi cách xử lý.
Nhưng tôi không muốn việc học hỏi diễn ra như một quá trình tự động không có kiểm soát.
Không phải cứ AI phát hiện một mẫu hình là chúng ta lập tức sửa chính sách.
Một tương quan không đủ để tạo ra một quy tắc kinh doanh.
Và một quyết định từng được chấp thuận nhiều lần không có nghĩa nó luôn đúng.
Những thay đổi quan trọng cần được kiểm chứng.
Có thể thử nghiệm trên phạm vi nhỏ.
Có thể so sánh với dữ liệu trước đó.
Có thể đo lường tác dụng phụ.
Và phải có khả năng quay lại cấu trúc cũ nếu kết quả không phù hợp.
Tôi thích suy nghĩ về chính sách như những thành phần có phiên bản.
Một quy tắc được tạo ra ở một thời điểm.
Dựa trên những giả định nhất định.
Được áp dụng cho một phạm vi cụ thể.
Có người chịu trách nhiệm.
Có lịch sử thay đổi.
Và có bằng chứng đánh giá hiệu quả.
Khi một quyết định được đưa ra, hệ thống có thể biết nó đã sử dụng phiên bản chính sách nào.
Điều đó quan trọng hơn nhiều so với tưởng tượng ban đầu.
Bởi vì khi một kết quả bất thường xuất hiện sau ba tháng, chúng ta cần phân biệt:
Đó là hậu quả của một quy tắc hiện tại?
Một quy tắc cũ?
Hay một quyết định ngoại lệ được đưa ra ngoài chính sách?
Nếu không thể truy vết, tổ chức sẽ rất khó học một cách chính xác.
Và nếu cứ mỗi lần xuất hiện vấn đề mới chúng ta lại sửa một loạt quy tắc mà không hiểu ảnh hưởng, hệ thống có thể ngày càng khó đoán.
A learning system does not merely accumulate rules. It improves the quality of the rules it chooses to keep.
Một hệ thống biết học không phải là hệ thống ngày càng có nhiều quy định.
Nó là hệ thống ngày càng biết rõ những quy định nào thực sự tạo ra giá trị.
Đôi khi, cải tiến tốt nhất không phải bổ sung một cơ chế mới.
Mà là loại bỏ một cơ chế đã trở nên không cần thiết.
Tôi đặc biệt thích những cải tiến như vậy.
Ít thứ phải vận hành hơn.
Ít thứ phải bảo trì hơn.
Và ít thứ có khả năng sai hơn.
Một chiến thắng khá toàn diện.
12. Khi hạ tầng chung đủ mạnh, sáng tạo không cần tập trung ở trung tâm.
Đây là phần khiến tôi thực sự hứng thú với Business Operating System.
Cho đến lúc này, chúng ta chủ yếu bàn về cách giúp tổ chức vận hành nhất quán.
Nhưng nếu chỉ có vậy, chúng ta có thể tạo ra một doanh nghiệp rất kỷ luật.
Chưa chắc có khả năng đổi mới.
Tôi muốn đi xa hơn.
Hãy tưởng tượng một doanh nghiệp có nhiều nhóm kinh doanh.
Mỗi nhóm hiểu một phân khúc khách hàng khác nhau.
Một nhóm chuyên về bao bì cho quán cà phê.
Một nhóm hiểu sâu về ngành bánh.
Một nhóm tập trung vào dịch vụ in ấn.
Một nhóm phát triển khách hàng doanh nghiệp.
Mỗi nhóm có những ý tưởng riêng.
Họ muốn tạo công cụ tư vấn.
Thiết kế quy trình chăm sóc.
Phát triển giải pháp kết hợp sản phẩm.
Xây dựng nội dung chuyên môn.
Hoặc thử nghiệm một phương pháp bán hàng mới.
Trong mô hình truyền thống, mỗi ý tưởng thường phải đi qua một quá trình.
Đề xuất.
Phê duyệt.
Chuyển yêu cầu cho IT.
Chờ phát triển.
Kiểm thử.
Triển khai.
Và có thể, sau vài tháng, ý tưởng mới được đưa vào thực tế.
Tôi không cho rằng quy trình đó luôn sai.
Những thay đổi ảnh hưởng đến hệ thống cốt lõi cần được kiểm soát.
Nhưng nếu mọi thử nghiệm nhỏ đều phải đi qua cùng một nút thắt, tổ chức sẽ bị giới hạn bởi năng lực xử lý của bộ phận trung tâm.
Tôi muốn một mô hình khác.
Shared Core. Distributed Innovation.
Một lõi năng lực chung.
Và khả năng đổi mới được phân tán.
Các thành phần quan trọng được cung cấp thông qua những interface có kiểm soát.
Định danh khách hàng.
Danh mục sản phẩm.
Chính sách giá.
Điều kiện giao dịch.
Quyền hạn.
Quy trình đặt hàng.
Dữ liệu phục vụ phân tích.
Những nhóm có đủ năng lực có thể sử dụng các thành phần đó để xây dựng những công cụ riêng.
Một nhóm tạo ứng dụng tư vấn sản phẩm.
Một nhóm tạo công cụ tính toán giải pháp cho khách hàng.
Một nhóm phát triển hệ thống theo dõi cơ hội của phân khúc mình phụ trách.
Một nhóm thử nghiệm quy trình chăm sóc khách hàng đặc thù.
Nhưng các ứng dụng đó không được tự ý phá vỡ những ràng buộc chung.
Chúng có thể sử dụng những capability mà nền tảng cung cấp.
Không có nghĩa được sở hữu toàn bộ hạ tầng.
Đây là một hướng tư duy gần với Internal Developer Platform.
Nhưng tôi không muốn giới hạn nó cho lập trình viên chuyên nghiệp.
Với sự phát triển của AI-assisted development, những người có kiến thức nghiệp vụ tốt có thể ngày càng tham gia sâu hơn vào quá trình tạo ra công cụ phục vụ công việc của chính mình.
Điều này rất hấp dẫn.
Bởi vì một nhân viên hiểu sâu về nhu cầu khách hàng có thể có những ý tưởng mà bộ phận kỹ thuật trung tâm khó tự nghĩ ra.
Nhưng tôi cũng thấy rõ rủi ro.
Nếu ai cũng có thể tạo phần mềm và kết nối trực tiếp vào dữ liệu production, chúng ta có thể nhanh chóng biến doanh nghiệp thành một tập hợp những ứng dụng không được kiểm soát.
Một người tạo bảng khách hàng riêng.
Một người viết lại logic giá.
Một người xây dựng hệ thống xử lý đơn khác.
Một người tạo automation cập nhật dữ liệu mà không hiểu đầy đủ những ràng buộc liên quan.
Và cả tổ chức có thể trở thành một thí nghiệm công nghệ quy mô lớn.
Không có kế hoạch khôi phục.
Khá thú vị.
Cho đến khi kế toán bắt đầu gọi điện.
Vì vậy, khả năng phát triển phân tán phải đi cùng những giới hạn rõ ràng.
Môi trường thử nghiệm phải được cách ly phù hợp.
Quyền truy cập dữ liệu phải được giới hạn.
Những thao tác tạo cam kết kinh doanh phải đi qua capability có thẩm quyền.
Và những thay đổi ảnh hưởng đến hạ tầng chung cần có cơ chế kiểm chứng và triển khai thích hợp.
Freedom to Build requires a platform that knows what must remain protected.
Tôi không muốn mọi nhân viên đều phải trở thành Software Engineer.
Nhưng tôi muốn những người có khả năng nhìn thấy cơ hội được trao công cụ để biến cơ hội đó thành sản phẩm.
Với mức rủi ro được kiểm soát.
Nếu làm tốt, doanh nghiệp không chỉ có một nhóm phát triển phần mềm.
Nó có thể phát triển một mạng lưới những người tạo ra giải pháp kinh doanh dựa trên hạ tầng chung.
Đó là một năng lực rất đáng giá.
13. AI không thay thế Business Operating System. Nó làm tăng nhu cầu phải có một hệ thống tốt.
Có một xu hướng mà tôi nghĩ sẽ ngày càng mạnh.
Con người bắt đầu sử dụng AI để thực hiện những công việc trước đây đòi hỏi kỹ năng chuyên môn khá cao.
Phân tích dữ liệu.
Viết phần mềm.
Tạo nội dung.
Tư vấn sản phẩm.
Tóm tắt thông tin.
Đề xuất quyết định.
Và thậm chí thực hiện nhiều bước công việc thông qua các công cụ được cấp quyền.
Tôi không xem AI chỉ là một chatbot đặt bên cạnh website.
Nó có thể trở thành một tầng năng lực mới trong kiến trúc vận hành.
Nhưng điều đó đặt ra một vấn đề rất quan trọng.
AI sẽ sử dụng sự thật kinh doanh nào?
Nó được phép đưa ra những quyết định gì?
Nó có quyền thực hiện những hành động nào?
Và hệ thống nào bảo đảm các hành động đó không vượt khỏi những giới hạn đã được định nghĩa?
Hãy tưởng tượng một AI assistant có thể tư vấn sản phẩm cho khách hàng.
Nó cần biết sản phẩm.
Hiểu quan hệ tương thích.
Biết những lựa chọn thay thế.
Hiểu chính sách thương mại.
Và có thể hỗ trợ tạo một giỏ hàng.
Nhưng nếu AI tự suy luận rằng hai sản phẩm tương thích chỉ vì tên gọi gần giống nhau, chúng ta có thể tạo ra một đề xuất sai.
Nếu nó sử dụng giá đã hết hiệu lực, chúng ta có thể tạo ra kỳ vọng không phù hợp.
Nếu nó tự hứa thời gian giao hàng mà không có thông tin về khả năng đáp ứng, doanh nghiệp có thể phải xử lý những cam kết không thể thực hiện.
Và nếu nó có quyền thay đổi giao dịch mà không đi qua các cơ chế kiểm soát, rủi ro còn lớn hơn.
Tôi muốn phân biệt rõ:
AI là một năng lực suy luận và hỗ trợ hành động.
Business Operating System xác định thực tế, quyền hạn và những điều kiện để hành động trở nên hợp lệ.
AI có thể đề xuất.
Có thể phân tích.
Có thể phát hiện mẫu hình.
Có thể giúp con người xây dựng những công cụ mới.
Và trong những phạm vi được thiết kế phù hợp, nó có thể thực hiện hành động.
Nhưng thẩm quyền không nên xuất phát từ sự tự tin trong câu trả lời của mô hình.
Một AI rất thông minh không tự động có quyền quyết định chính sách giá.
Cũng như một nhân viên rất giỏi không tự động có quyền thay đổi hạn mức tín dụng của toàn bộ doanh nghiệp.
Tôi muốn AI sử dụng những capability được cấp quyền, với dữ liệu và ràng buộc phù hợp.
Những quyết định có rủi ro cao cần mức kiểm soát tương ứng.
Những hành động quan trọng cần có khả năng truy vết.
Và những kết quả bất thường phải có cơ chế phát hiện, khắc phục.
AI amplifies intelligence. Architecture determines whether that intelligence creates value or chaos.
AI khuếch đại năng lực xử lý thông tin.
Kiến trúc quyết định năng lực đó tạo ra giá trị hay hỗn loạn.
Nếu hệ thống nền tảng thiếu nhất quán, AI có thể khiến những điểm yếu đó xuất hiện nhanh hơn, thường xuyên hơn và trên phạm vi lớn hơn.
Ngược lại, nếu doanh nghiệp có dữ liệu có cấu trúc, quyền hạn rõ ràng và các capability đáng tin cậy, AI có thể mở rộng đáng kể khả năng sử dụng những năng lực ấy.
Đây là lý do tôi không cho rằng chỉ cần mua một phần mềm có tích hợp AI là doanh nghiệp đã bước sang một giai đoạn vận hành mới.
Công nghệ có thể rất mạnh.
Nhưng nếu những nguyên tắc kinh doanh chưa được định nghĩa đủ rõ, AI chỉ đang bước vào một căn phòng mà không ai biết chính xác ai có quyền quyết định điều gì.
Và bắt đầu trả lời với sự tự tin tuyệt đối.
Tôi từng gặp đủ người như vậy rồi.
Không nhất thiết cần thêm một phiên bản chạy trên GPU.
14. Kiến trúc tốt không bảo đảm tổ chức có khả năng vận hành nó.
Đây có lẽ là phần khó chịu nhất đối với một người xuất thân kỹ thuật.
Chúng ta có thể thiết kế một hệ thống rất tốt.
Logic rõ ràng.
Dữ liệu có cấu trúc.
Ràng buộc chặt chẽ.
Quyền hạn được phân định.
Các công cụ được tích hợp.
Khả năng quan sát tương đối đầy đủ.
Nhưng tổ chức vẫn có thể không vận hành tốt.
Tại sao?
Bởi vì chất lượng của kiến trúc và năng lực hấp thụ kiến trúc của tổ chức không phải cùng một thứ.
Một người thiết kế có thể hiểu toàn bộ hệ thống.
Nhưng nhân viên chỉ nhìn thấy phần công việc mà họ đang thực hiện.
Một thay đổi có thể hoàn toàn hợp lý ở góc độ toàn cục nhưng làm tăng gánh nặng cho một bộ phận cụ thể.
Một quy trình mới có thể giảm rủi ro dài hạn nhưng đòi hỏi thay đổi thói quen đã tồn tại nhiều năm.
Một công cụ có thể giúp công việc hiệu quả hơn, nhưng chỉ khi người sử dụng hiểu đúng cách áp dụng.
Và một cơ chế phân quyền có thể được thiết kế rất tốt, nhưng vẫn thất bại nếu những người được trao quyền chưa đủ năng lực phán đoán.
Đây là một giới hạn thực tế mà phần mềm không thể tự mình giải quyết.
An organization cannot execute an architecture it has not learned to understand.
Một tổ chức không thể thực thi tốt một kiến trúc mà nó chưa học cách hiểu.
Nhưng tôi cũng không nghĩ tất cả nhân viên phải hiểu toàn bộ kiến trúc.
Điều đó không thực tế.
Một nhân viên kho không cần hiểu chiến lược phát triển thị trường ba năm tới để thực hiện tốt quy trình chuẩn bị hàng.
Một nhân viên bán hàng không cần hiểu các chi tiết của transaction isolation để tuân thủ chính sách công nợ.
Nhưng họ phải hiểu những quyết định thuộc phạm vi trách nhiệm của mình.
Phải biết thông tin nào đáng tin cậy.
Phải biết khi nào được quyền tự xử lý.
Phải biết khi nào cần đưa vấn đề lên cấp cao hơn.
Và phải hiểu những hậu quả quan trọng của quyết định mình đang đưa ra.
Đây là lý do hệ thống phải được thiết kế phù hợp với năng lực thực tế của người sử dụng.
Không phải hình mẫu nhân viên lý tưởng trong đầu người thiết kế.
Nếu một quy trình chỉ hoạt động tốt khi người thực hiện có năng lực phân tích rất cao, nhưng doanh nghiệp đang sử dụng nó cho những vị trí có yêu cầu kỹ năng cơ bản, có thể vấn đề nằm ở thiết kế.
Nếu một giao diện đòi hỏi người dùng phải ghi nhớ hàng chục điều kiện để tránh sai, có thể chúng ta đang chuyển gánh nặng của kiến trúc sang con người.
Nhưng nếu một người đã được cung cấp đủ điều kiện vẫn liên tục không đáp ứng yêu cầu tối thiểu, đó có thể là vấn đề nhân sự.
Hai điều này cần được phân biệt.
Tôi không muốn dùng phần mềm để che giấu mọi vấn đề năng lực.
Nhưng cũng không muốn dùng lý do năng lực để biện minh cho một kiến trúc tồi.
Một tổ chức trưởng thành cần cả hai.
Kiến trúc phù hợp.
Và những con người có khả năng thực hiện trách nhiệm của mình.
15. Khi tốc độ phát triển hệ thống vượt quá tốc độ phát triển tổ chức.
Có một nghịch lý mà tôi nghĩ những founder có nền tảng kỹ thuật mạnh rất dễ gặp.
Khi nhìn thấy một vấn đề, họ có thể nhanh chóng nhận diện cấu trúc.
Khi nhận diện được cấu trúc, họ có thể thiết kế giải pháp.
Khi có đủ năng lực kỹ thuật, họ thậm chí có thể tự triển khai giải pháp đó.
Toàn bộ chu kỳ có thể diễn ra rất nhanh.
Quan sát.
Phân tích.
Thiết kế.
Phát triển.
Triển khai.
Và tiếp tục cải tiến.
Trong giai đoạn đầu, đây là một lợi thế rất lớn.
Doanh nghiệp có thể liên tục xây dựng những năng lực mới mà không phải phụ thuộc quá nhiều vào nhà cung cấp bên ngoài.
Nhưng đến một thời điểm, tốc độ phát triển của hệ thống có thể vượt khỏi tốc độ hấp thụ của tổ chức.
Một tính năng mới được triển khai.
Nhân viên chưa kịp hiểu hết.
Một cơ chế mới tiếp tục xuất hiện.
Bộ phận vận hành chưa kịp điều chỉnh thói quen.
Một quy trình được thiết kế lại.
Người quản lý vẫn đang sử dụng cách đánh giá cũ.
Và một công cụ mới được đưa vào hoạt động trước khi tổ chức thực sự khai thác hết những công cụ trước đó.
Lúc này, việc phát triển thêm phần mềm chưa chắc còn là yếu tố giới hạn tăng trưởng.
The bottleneck has moved.
Nút thắt đã di chuyển.
Từ năng lực phát triển công nghệ sang năng lực vận hành và hấp thụ thay đổi.
Một founder có thể xây dựng mười công cụ mới trong một tháng.
Nhưng nếu tổ chức chỉ có khả năng triển khai hiệu quả hai công cụ, tám công cụ còn lại có nguy cơ trở thành năng lực chưa được khai thác.
Tệ hơn, chúng có thể tạo ra thêm sự phức tạp.
Nhân viên phải học nhiều quy trình hơn.
Quản lý phải theo dõi nhiều trạng thái hơn.
Dữ liệu có thêm nhiều nguồn cập nhật.
Và những thay đổi liên tục khiến tổ chức khó hình thành thói quen vận hành ổn định.
Tôi nghĩ đây là lúc người thiết kế phải thay đổi cách đánh giá thành công.
Không phải một tháng đã triển khai bao nhiêu tính năng.
Mà là bao nhiêu năng lực mới đã thực sự trở thành một phần đáng tin cậy của hoạt động kinh doanh.
Một tính năng được triển khai không đồng nghĩa với một năng lực đã được hình thành.
Một quy trình được công bố không đồng nghĩa với một quy trình đã được hấp thụ.
Một dashboard được tạo ra không đồng nghĩa với việc những người quản lý đang đưa ra quyết định tốt hơn.
Và một hệ thống AI được tích hợp không đồng nghĩa với việc doanh nghiệp đã trở nên thông minh hơn.
Deployment is an engineering event. Adoption is an organizational process. Capability is the actual business outcome.
Ba thứ đó cần được phân biệt.
Tôi không cho rằng giải pháp luôn là giảm tốc độ phát triển.
Đôi khi chúng ta cần duy trì tốc độ cao để tạo ra lợi thế cạnh tranh.
Nhưng phải có khả năng phân bổ năng lực triển khai, đào tạo và kiểm chứng tương ứng.
Nếu không, tổ chức sẽ liên tục chạy theo hệ thống.
Thay vì hệ thống phục vụ tổ chức.
Một tình huống khá trớ trêu.
Đặc biệt khi hệ thống được xây dựng với mục tiêu ban đầu là giúp con người làm việc hiệu quả hơn.
16. Người lãnh đạo vận hành là thành phần không thể thay thế bằng một dashboard.
Có một điều tôi muốn nói rõ.
Business Operating System không loại bỏ nhu cầu về lãnh đạo vận hành.
Ngược lại, khi hệ thống ngày càng có nhiều năng lực, vai trò vận hành có thể trở nên quan trọng hơn.
Bởi vì phần mềm có thể thực thi những quy tắc đã được định nghĩa.
Nhưng việc tổ chức con người, phát triển năng lực, giải quyết xung đột giữa những mục tiêu và bảo đảm chất lượng thực thi vẫn cần trách nhiệm quản trị.
Một hệ thống có thể cho biết một bộ phận đang xử lý chậm.
Nhưng người lãnh đạo vận hành cần xác định nguyên nhân.
Thiếu công suất?
Thiếu kỹ năng?
Cấu trúc công việc không hợp lý?
Dữ liệu chưa đầy đủ?
Hay những ưu tiên đang mâu thuẫn?
Một dashboard có thể cho biết tỷ lệ sai sót tăng.
Nhưng không thể mặc nhiên kết luận đó là lỗi của người thực hiện.
Một hệ thống có thể phát hiện một nhóm nhân viên đang sử dụng công cụ mới ít hơn dự kiến.
Nhưng việc xác định công cụ không phù hợp hay nhân viên chưa đủ năng lực vẫn cần đánh giá thực tế.
Tôi không muốn người lãnh đạo vận hành trở thành người chuyên đi kiểm tra nhân viên có làm đúng những gì phần mềm yêu cầu hay không.
Tôi muốn họ chịu trách nhiệm về năng lực vận hành thực tế của tổ chức.
Khả năng hấp thụ thay đổi.
Chất lượng thực thi.
Mức độ ổn định.
Khả năng xử lý ngoại lệ.
Sự phối hợp giữa các bộ phận.
Và việc phát triển những con người có thể nhận thêm trách nhiệm khi doanh nghiệp mở rộng.
Phần mềm cung cấp hạ tầng.
Kiến trúc cung cấp nguyên tắc.
Nhưng người lãnh đạo vận hành phải biến những nguyên tắc đó thành hành vi tập thể.
Đây là một loại năng lực khác với Software Engineering.
Một người có thể cực kỳ giỏi thiết kế hệ thống nhưng không đủ giỏi dẫn dắt một đội ngũ lớn.
Ngược lại, một người có thể rất giỏi tổ chức con người nhưng không có khả năng tự thiết kế kiến trúc công nghệ.
Tôi không xem một trong hai năng lực cao quý hơn năng lực còn lại.
Chúng giải quyết những vấn đề khác nhau.
Và một doanh nghiệp muốn mở rộng cần biết kết hợp chúng.
Technology creates leverage. Operations turns leverage into repeatable performance.
Công nghệ tạo ra đòn bẩy.
Vận hành biến đòn bẩy thành kết quả có thể lặp lại.
Nếu thiếu công nghệ phù hợp, tổ chức có thể phải dùng quá nhiều nguồn lực cho những công việc đã có thể cấu trúc hóa.
Nếu thiếu năng lực vận hành, công nghệ có thể trở thành một bộ sưu tập những chức năng rất ấn tượng nhưng không được khai thác hiệu quả.
Tôi không muốn lựa chọn giữa hai thứ.
Tôi muốn một kiến trúc cho phép cả hai cùng phát triển.
17. Người thiết kế không nên trở thành hệ điều hành của chính doanh nghiệp mình.
Đây là một nghịch lý khác mà tôi muốn nhìn thẳng.
Trong nhiều doanh nghiệp, người sáng lập thực sự là Operating System.
Họ biết khách hàng quan trọng.
Biết sản phẩm nào mang lại lợi nhuận tốt.
Biết nhân viên nào có năng lực.
Biết nhà cung cấp nào đáng tin cậy.
Biết khi nào phải linh hoạt và khi nào cần giữ nguyên tắc.
Biết những ngoại lệ nào có thể chấp nhận.
Và có thể kết nối thông tin từ nhiều bộ phận để đưa ra quyết định.
Khi tổ chức nhỏ, cách vận hành này có thể rất hiệu quả.
Một người có khả năng nhìn toàn cục có thể phối hợp những thành phần khác nhanh hơn nhiều so với việc xây dựng một bộ máy quản trị cồng kềnh.
Nhưng khi quy mô tăng, mô hình đó bắt đầu có giới hạn.
Mọi thông tin quan trọng đều phải được đưa đến founder.
Mọi quyết định khó đều cần founder tham gia.
Mọi thay đổi lớn đều phải được founder giải thích.
Và khi một tình huống chưa có tiền lệ xuất hiện, cả tổ chức lại chờ người có khả năng nhìn thấy cấu trúc.
Lúc này, doanh nghiệp không thực sự có một Operating System độc lập.
Nó có một con người đóng vai trò hệ điều hành.
Một con người có thể rất giỏi.
Nhưng vẫn chỉ có hai mươi bốn giờ mỗi ngày.
Vẫn có giới hạn tập trung.
Vẫn cần nghỉ ngơi.
Và vẫn có thể mắc sai lầm.
Tôi thấy đây là một mô hình có độ rủi ro rất cao.
Không phải vì founder thiếu năng lực.
Mà chính vì founder có quá nhiều năng lực mà tổ chức chưa chuyển hóa được thành những cơ chế có thể vận hành độc lập.
Điều này không thể giải quyết chỉ bằng cách bổ nhiệm thêm quản lý.
Nếu người mới vẫn phải hỏi founder về mọi quyết định quan trọng, chúng ta chỉ vừa tạo ra thêm một tầng truyền đạt.
Sơ đồ tổ chức trở nên cao hơn.
Quyền quyết định vẫn nằm ở cùng một chỗ.
Và thời gian xử lý có thể còn lâu hơn trước.
Tôi muốn một cách tiếp cận khác.
Những quyết định đã hiểu rõ được chuyển thành chính sách và cơ chế.
Những quyết định có thể phân quyền được giao cho người có đủ năng lực và thông tin.
Những trách nhiệm vận hành được phân định rõ.
Những ngoại lệ thực sự cần phán đoán được đưa đến đúng cấp.
Và những vấn đề chiến lược vẫn thuộc phạm vi của những người chịu trách nhiệm cao nhất.
Điều đó không có nghĩa founder mất quyền kiểm soát.
Nó có nghĩa quyền kiểm soát được thực thi thông qua kiến trúc thay vì sự can thiệp liên tục.
A founder should design the operating system, not become the operating system.
Tôi đặc biệt thích nguyên lý này.
Bởi vì nếu người sáng lập vừa là kiến trúc sư, vừa là bộ xử lý trung tâm, vừa là cơ chế phê duyệt, vừa là hệ thống xử lý ngoại lệ, doanh nghiệp sẽ rất khó phát triển vượt khỏi giới hạn cá nhân đó.
Có thể phát triển rất nhanh trong một giai đoạn.
Nhưng không thể mở rộng mãi theo cùng một cách.
Và nếu founder còn tự hào rằng không ai có thể thay thế mình?
Tôi nghĩ anh ta nên xem lại định nghĩa thành công.
Bởi vì một doanh nghiệp không thể hoạt động nếu người sáng lập nghỉ hai tuần không nhất thiết chứng minh người sáng lập xuất sắc.
Nó có thể chỉ chứng minh rằng doanh nghiệp chưa được thiết kế để hoạt động mà không có anh ta.
Một lời khen khá độc hại.
18. Business Operating System phải tạo ra năng lực, không phải sự phụ thuộc mới.
Sau tất cả, tôi nghĩ một Business Operating System tốt phải vượt qua một bài kiểm tra rất đơn giản.
Khi doanh nghiệp phát triển, nó có khiến những người bên trong trở nên có năng lực hơn hay không?
Một nhân viên mới có thể đưa ra quyết định tốt hơn nhờ được cung cấp thông tin, hướng dẫn và những ràng buộc phù hợp?
Một nhân viên có kinh nghiệm có thể xử lý nhiều tình huống hơn mà không cần xin phép?
Một quản lý có thể phát triển đội ngũ mà không phải tự mình giải quyết từng vấn đề?
Một nhóm kinh doanh có thể thử nghiệm phương pháp mới mà không cần xây dựng lại toàn bộ hạ tầng?
Và một người xuất sắc có thể tạo ra giá trị vượt khỏi giới hạn công việc trực tiếp của họ?
Nếu câu trả lời là có, kiến trúc đang tạo ra một dạng đòn bẩy có ý nghĩa.
Nhưng nếu mọi hoạt động vẫn cần một vài người giải thích.
Nếu mọi thay đổi đều phải chờ nhóm kỹ thuật trung tâm.
Nếu nhân viên ngày càng phụ thuộc vào hệ thống mà không hiểu những quyết định quan trọng.
Nếu những quy tắc trở nên phức tạp đến mức không ai có khả năng kiểm chứng.
Và nếu hệ thống chỉ hoạt động tốt khi người thiết kế vẫn trực tiếp theo dõi mọi thứ.
Thì chúng ta có thể đã tạo ra một dạng phụ thuộc mới.
Trước đây doanh nghiệp phụ thuộc vào trí nhớ của người quản lý.
Bây giờ phụ thuộc vào một kiến trúc phần mềm mà không ai khác hiểu.
Sự thay đổi đó chưa chắc là tiến bộ.
Tôi muốn một hệ thống có thể được hiểu, vận hành, kiểm chứng và phát triển bởi ngày càng nhiều người có năng lực phù hợp.
Không phải ai cũng cần hiểu toàn bộ.
Nhưng tri thức quan trọng không nên bị khóa vĩnh viễn trong đầu một cá nhân.
Kể cả khi cá nhân đó là người đã tạo ra hệ thống.
Đây là lý do kiến trúc phải đi cùng khả năng truyền đạt.
Tài liệu có ý nghĩa.
Những contract rõ ràng.
Quyền hạn minh bạch.
Khả năng quan sát.
Cơ chế thử nghiệm.
Và những con người có thể nhận trách nhiệm thực sự.
The ultimate purpose of a Business Operating System is not to make the business dependent on better software. It is to make the organization more capable of operating, learning and evolving.
Đích đến không phải một doanh nghiệp phụ thuộc vào phần mềm tốt hơn.
Mà là một tổ chức có năng lực vận hành, học hỏi và tiến hóa tốt hơn.
Phần mềm chỉ là một thành phần trong hành trình đó.
Dù phải thừa nhận, đó là thành phần tôi đặc biệt thích xây dựng.
Một sở thích tương đối tốn kém.
Nhất là khi người có sở thích đó cũng là người duyệt ngân sách.
Lời kết: The Business Operating System.
Tôi không cho rằng một doanh nghiệp có thể được thiết kế hoàn hảo như một hệ thống máy tính.
Con người quá phức tạp.
Thị trường quá biến động.
Và những quyết định kinh doanh luôn tồn tại những yếu tố không thể được mô hình hóa đầy đủ.
Nhưng điều đó không có nghĩa chúng ta nên chấp nhận sự hỗn loạn như một trạng thái tất yếu.
Có những vấn đề không cần phải xuất hiện lặp đi lặp lại.
Có những quyết định không cần liên tục được đưa đến người quản lý.
Có những thông tin không nên tồn tại dưới năm phiên bản khác nhau.
Có những quy tắc không nên chỉ sống trong trí nhớ.
Và có những năng lực đã được khám phá không nên biến mất khi một nhân viên rời khỏi tổ chức.
Tôi muốn một kiến trúc có khả năng giải quyết những điều đó.
Một kiến trúc biết doanh nghiệp đang sở hữu những gì.
Biết những ràng buộc nào cần được bảo vệ.
Biết ai có quyền đưa ra quyết định.
Biết những cam kết nào đã được tạo ra.
Biết công việc phải được thực hiện qua những trạng thái nào.
Biết khi nào cần con người can thiệp.
Và có khả năng học từ những kết quả mà nó tạo ra.
Tôi không muốn mọi quyết định được đưa ra bởi một bộ máy trung tâm.
Tôi muốn những quyết định phù hợp được thực hiện tại những nơi có đủ thông tin, năng lực và quyền hạn.
Tôi không muốn mọi nhân viên phải trở thành chuyên gia về kiến trúc kinh doanh.
Tôi muốn kiến trúc đủ tốt để họ có thể làm việc hiệu quả trong phạm vi trách nhiệm của mình.
Và tôi không muốn mọi sáng kiến đều phải bắt đầu từ founder.
Tôi muốn một nền tảng cho phép ngày càng nhiều người có thể tự tạo ra những giải pháp mới.
Đó là cách tôi nhìn nhận Business Operating System.
Không phải hệ thống kiểm soát mọi hành động.
Mà là hạ tầng giúp những hành động độc lập có thể kết hợp thành kết quả chung có ý nghĩa.
Shared truth. Clear authority. Enforced constraints. Coordinated execution. Continuous learning.
Một thực tế chung.
Quyền hạn rõ ràng.
Ràng buộc được thực thi.
Hoạt động được phối hợp.
Và khả năng học hỏi liên tục.
Tôi nghĩ đó là năm điều mà một kiến trúc vận hành trưởng thành phải hướng đến.
Không nhất thiết phải sử dụng một công nghệ cụ thể.
Không nhất thiết phải triển khai tất cả cùng lúc.
Và chắc chắn không cần phải xây dựng một phần mềm khổng lồ chỉ để có thể gọi nó là Operating System.
Điều quan trọng là những năng lực đó có thực sự tồn tại trong cách doanh nghiệp hoạt động hay không.
Nếu một nhân viên có thể tự xử lý một tình huống đã hiểu rõ, đó là tiến bộ.
Nếu một bộ phận không còn phải gọi điện để xác minh một thông tin đáng lẽ phải chính xác, đó là tiến bộ.
Nếu một ngoại lệ được chuyển thành một cơ chế giúp hàng nghìn giao dịch tiếp theo vận hành tốt hơn, đó là tiến bộ.
Nếu một nhóm có thể xây dựng giải pháp kinh doanh mới mà không phá vỡ những ràng buộc chung, đó là tiến bộ.
Và nếu người sáng lập có thể rời khỏi hoạt động thường ngày mà tổ chức vẫn tiếp tục vận hành đáng tin cậy, đó là một dạng tiến bộ rất đáng giá.
Bởi vì đỉnh cao của người thiết kế không phải tạo ra một hệ thống mà chỉ mình họ có thể điều khiển.
Mà là tạo ra một hệ thống có khả năng tiếp tục vận hành, phát triển và được cải thiện bởi những người khác.
The architect's greatest achievement is not building a system that needs him. It is building a system that can grow beyond him.
Tôi không nghĩ điều đó dễ dàng.
Đặc biệt đối với những người đã quen tự mình giải quyết những vấn đề khó nhất của doanh nghiệp.
Chúng ta có thể nhìn thấy cấu trúc.
Có thể thiết kế cơ chế.
Có thể tự viết phần mềm.
Và có thể triển khai những ý tưởng mới nhanh hơn khả năng tổ chức hấp thụ chúng.
Chính năng lực đó vừa là lợi thế.
Vừa có thể trở thành giới hạn.
Vì vậy, đến một thời điểm, câu hỏi quan trọng nhất của người sáng lập có lẽ không còn là:
"Tôi có thể xây dựng thêm điều gì?"
Mà là:
"Tôi đã xây dựng được bao nhiêu năng lực mà tổ chức thực sự có thể sử dụng và phát triển khi không cần đến tôi?"
Một câu hỏi khó chịu.
Bởi vì nó không cho phép chúng ta chỉ khoe số lượng tính năng.
Không cho phép lấy kiến trúc phần mềm làm bằng chứng cho chất lượng vận hành.
Và không cho phép đồng nhất năng lực cá nhân của founder với năng lực thực sự của doanh nghiệp.
Nhưng tôi nghĩ đó là câu hỏi đáng để theo đuổi.
Tôi không muốn xây dựng một doanh nghiệp nơi tất cả mọi người đều phải suy nghĩ giống mình.
Tôi muốn xây dựng một doanh nghiệp nơi những con người có năng lực khác nhau có thể đưa ra những quyết định tốt trong một kiến trúc chung.
Và nơi những người thực sự xuất sắc có thể tạo ra những điều mà ngay cả người thiết kế ban đầu cũng chưa từng hình dung.
Đó là lúc Business Operating System trở thành một năng lực cạnh tranh thực sự.
Không phải vì nó có nhiều chức năng hơn.
Mà vì nó cho phép tổ chức làm được những điều mà trước đây chỉ một vài cá nhân có thể thực hiện.
Và sau khi những năng lực đó đã được xây dựng, chúng ta có thể bắt đầu đặt câu hỏi tiếp theo.
Những công việc nào vẫn đang tiêu tốn thời gian của con người một cách không cần thiết?
Những quyết định nào đã đủ rõ để không phải lặp lại quá trình phân tích?
Những thao tác nào có thể được tự động hóa mà không làm mất khả năng kiểm soát?
Và làm sao để con người dành phần lớn năng lực của mình cho những vấn đề mới, thay vì tiếp tục xử lý những thứ đã được hiểu từ rất lâu?
Đó là bước tiếp theo.
Bởi vì một tổ chức có Operating System tốt không nên chỉ hoạt động nhất quán hơn.
Nó còn phải biết cách giải phóng năng lực con người khỏi những công việc không còn cần đến khả năng phán đoán của họ.
Và nếu sau tất cả những gì đã xây dựng, tôi vẫn phải thức dậy mỗi sáng để giải quyết cùng một nhóm vấn đề, phê duyệt cùng một loại ngoại lệ và giải thích cùng một nguyên tắc cho những người khác nhau...
Có lẽ tôi không thực sự xây dựng một Business Operating System.
Tôi chỉ đang xây một phần mềm cực kỳ đắt tiền.
Để quản lý một doanh nghiệp vẫn chạy bằng não của tôi.
A very expensive external hard drive for a single human brain.
Không tệ nếu mục tiêu là lưu trữ dữ liệu.
Nhưng khá thảm hại nếu mục tiêu là xây dựng một tổ chức có khả năng mở rộng.
Và điều đáng sợ nhất?
Tôi có thể đã dành nhiều năm để xây dựng nó.
Trong khi vẫn tin rằng mình đang làm một điều rất thông minh.
Fuck.
Perhaps the system isn't the bottleneck anymore.
Perhaps I am.
NEXT CHAPTER — AUTOMATE THE ORDINARY
Tự động hóa không phải để thay thế con người. Nó là cách chúng ta ngừng lãng phí năng lực con người vào những vấn đề đã được hiểu rõ.
The Architect of Chaos — Ông Chú Hay Chửi