Operational Ontology Là Gì (Và Không Phải Là Gì)

Hãy mở bảng tính mà vận hành của bạn thực sự chạy trên đó. Không phải sơ đồ tổ chức — mà là bảng tính. Cái bảng có một hàng cho mỗi đơn hàng, một cột cho ngày giao, một cột cho số lượng, một cột nơi ai đó gõ tay tên khách hàng. Nó hoạt động. Nó đã hoạt động nhiều năm. Và nó không thể trả lời câu hỏi bạn hỏi nó nhiều nhất: *nếu đơn này trượt, còn gì hỏng theo?*

Nó không trả lời được vì câu trả lời không nằm trong ô nào. Nó sống trong các kết nối — đơn này cần vật liệu kia, vật liệu kia đến từ nhà cung cấp này, nhà cung cấp này đã trễ ba ngày hai lần trong quý này — và một bảng tính không có chỗ nào để chứa một kết nối. Nó có hàng và cột. Các mối quan hệ rơi xuống sàn, và người của bạn nhặt chúng lên bằng tay, từ trí nhớ, mỗi ngày.

Một bảng tính lưu cái bạn đã gõ. Một ontology lưu cái được kết nối.

Chúng tôi đã viết trước đây về vì sao một operational ontology là hệ điều hành cho quyết định, và vì sao kiến trúc Palantir xây cho Fortune 100 chính là thứ một vận hành công nghiệp quy mô vừa cần. Bài này đi xuống thêm một tầng — vào phần đi dây. Một operational ontology thực sự *được làm từ gì*, nó trông ra sao trên một lát công việc thật, và đến đâu thì nó thôi là một cơ sở dữ liệu hào nhoáng? Bài trước là *vì sao*; bài này là *cái gì* và *như thế nào*.

Trả lời trực tiếp:

Operational ontology là một mô hình kết nối duy nhất của vận hành của bạn, được dựng từ bốn phần: những thứ có thật trong doanh nghiệp (đối tượng), điều bạn biết về mỗi thứ (thuộc tính), cách chúng kết nối (mối quan hệ), và điều bạn có thể làm (hành động). Khác với một data model phẳng, nó giữ các mối quan hệ — nên phần mềm và AI có thể suy luận xuyên suốt vận hành và hành động trên nó.

Bốn phần, một cách cụ thể

Bỏ đi cái từ hàn lâm thì một operational ontology là bốn khối xây dựng. Hầu hết mọi người đã nghe "đối tượng và mối quan hệ" rồi gật gù mà chưa từng thấy điều đó nghĩa là gì vào một ngày thứ Ba. Vậy nên đây, trên một lát công việc bạn sẽ nhận ra.

1. Đối tượng — những thứ có thật, được định nghĩa một lần

Một đối tượng là một thứ có thật trong vận hành mà hệ thống hiểu như một thực thể duy nhất: một đơn hàng, một máy, một vật liệu, một khách hàng, một lệnh sản xuất, một địa điểm, một nhà cung cấp. Từ khóa là *một lần*. Hôm nay "Đơn DC-1042" tồn tại như một hàng trong sổ đơn hàng, một hàng khác trong bảng giao hàng, một dòng trong email, và một con số trên bảng trắng. Bốn bản sao, không bản nào là chuẩn, mỗi bản trôi khỏi các bản còn lại ngay khoảnh khắc một bản được cập nhật còn phần còn lại thì không.

Trong một ontology chỉ có một Đơn DC-1042. Một đối tượng. Mọi thứ khác — trạng thái giao hàng, hóa đơn, lịch dưới xưởng — trỏ *vào* nó thay vì giữ một bản sao riêng. Khi ngày giao thay đổi, nó thay đổi ở một chỗ, và mọi thứ được kết nối thấy ngay lập tức. Không có cuộc họp đối chiếu; chưa từng có bản sao thứ hai để đối chiếu.

2. Thuộc tính — điều bạn biết về mỗi thứ

Thuộc tính là những sự thật đi cùng một đối tượng. Của một đơn hàng: ngày giao, số lượng, giá trị, khách hàng, mức ưu tiên. Của một máy: dây chuyền, tốc độ chu kỳ, ngày bảo trì gần nhất, trạng thái. Của một vật liệu: số lượng tồn kho, lead time, đơn giá, các phương án thay thế được phép.

Cái này trông giống các cột trong bảng tính của bạn, và đó là cái bẫy — đó là lý do người ta cho rằng ontology "chỉ là một cơ sở dữ liệu." Khác biệt không nằm ở thuộc tính. Nó nằm ở chỗ thuộc tính treo trên một đối tượng được kết nối với mọi thứ khác, nên khoảnh khắc nó vượt một lằn ranh bạn quan tâm — số tồn kho tụt xuống dưới mức các đơn đã đặt cần — hệ thống có thể *đi theo kết nối* tới cái giờ đang rủi ro. Một cột không đi theo được gì. Nó giữ một con số cho đến khi một con người nghĩ tới việc đọc nó.

3. Mối quan hệ — cách các thứ kết nối

Đây là phần mà một data model phẳng về mặt cấu trúc không thể giữ, và đó là toàn bộ điểm mấu chốt. Một mối quan hệ là một liên kết có thật, hạng nhất, giữa hai đối tượng:

• Đơn này cần vật liệu kia.
• Vật liệu kia đến từ nhà cung cấp này.
• Lệnh sản xuất này làm ra sản phẩm kia.
• Máy này nuôi lô giao kia.
• Lô giao này đi tới khách hàng kia.

Đọc chúng từ trái sang phải và bạn đã mô tả một chuỗi mà, hôm nay, tồn tại ở đúng một chỗ: trong đầu bạn. Bạn biết rằng nếu ballistic nylon trễ, túi Eagle-9 không được làm, đơn DC-1042 lỡ ngày giao, và Calloway — một khách hàng không chịu được trượt — nhận một cuộc gọi bạn không muốn thực hiện. Bạn biết cả chuỗi. Bảng tính của bạn biết bốn con số rời rạc.

Khi các mối quan hệ được ghi lại như những đối tượng theo đúng nghĩa của chúng, phần mềm cũng biết chuỗi đó. Vật liệu sắp thiếu không chỉ làm một ô chuyển đỏ. Nó *lan truyền* — hệ thống đi qua các mối quan hệ và cho bạn biết, trong một nước đi, rằng đơn của Calloway giờ đang rủi ro. Việc đi xuyên đó là toàn bộ lý do một ontology tồn tại. Mọi thứ khác là sổ sách.

Khi được đi dây, chuỗi không còn là một sơ đồ bảng trắng — nó là một sống lưng mà hệ thống có thể đi từ đầu đến cuối. Một lát, mang tính minh họa, vẽ theo cách MIDAS giữ nó:

```mock

connected

```

4. Hành động — điều bạn thực sự có thể làm

Phần cuối là phần mà gần như mọi "data model" bỏ sót hoàn toàn. Một hành động là một thao tác hệ thống có thể thực hiện và ghi ngược lại thế giới thật của bạn: đặt lại vật liệu, sắp lại dây chuyền, giao lại lệnh sản xuất, mở một nhiệm vụ cho một owner, thông báo cho nhà cung cấp.

Một data model chỉ đọc là một báo cáo: nó cho bạn thấy vấn đề rồi để bạn tự sửa qua sáu hệ thống khác bằng tay. Một ontology có hành động khép kín vòng: nó biến "đơn của Calloway đang rủi ro vì nylon thiếu" thành một nhiệm vụ thật — *kiểm tra và đặt lại 600 m ballistic nylon, owner: John, cần trước ngày 14* — được ghi ngược lại hệ thống John làm việc, với bản ghi ai đã làm và khi nào. Bản đồ — đối tượng, thuộc tính, mối quan hệ — cho bạn biết điều gì là thật. Các hành động thay đổi điều gì là thật. Không có chúng, bạn có một cách rất đắt để phát hiện ra bạn đã trễ.

Bốn phần. Đối tượng, thuộc tính, mối quan hệ, hành động. Ba phần đầu để hệ thống *hiểu* vận hành của bạn; phần thứ tư để nó *chạy* vận hành đó.

Ontology so với một data model phẳng: khác biệt thực sự quan trọng

Người ta gộp hai thứ này lại vì cả hai đều "lưu dữ liệu của bạn." Chúng không phải cùng một loại thứ.

Một kho dữ liệu là một phiên bản tráng lệ của cột bên trái: nó giữ mọi hàng vận hành của bạn từng tạo ra, rẻ, mãi mãi — hữu ích, để nhìn lại phía sau. Nhưng lưu trữ không giống một quyết định. (Chúng tôi đi sâu hơn trong operational ontology so với kho dữ liệu.) Một kho dữ liệu có thể cho bạn biết cực kỳ chi tiết rằng bạn đã lỡ ba lô giao quý trước. Nó không thể nói bạn sắp lỡ lô thứ tư, vì "sắp" sống trong các mối quan hệ — đơn đã đặt so với tồn kho sống so với lead time nhà cung cấp — và nó lưu các con số, không lưu phần đi dây giữa chúng.

Đây là nơi hóa đơn cho một mô hình phẳng rơi xuống, ở hai chỗ. Chỗ thứ nhất là chi phí cứng. Gartner đã thấy rằng chất lượng dữ liệu kém khiến các tổ chức tốn trung bình 12,9 triệu đô la mỗi năm. Đọc nó với tư cách một người vận hành, không phải một CIO: phần lớn không phải một lỗi gõ trong một ô. Đó là sự *mất kết nối* — cùng một đơn sống như bốn bản sao trôi dạt, con số tồn kho cũ ba ngày, sự chậm trễ của nhà cung cấp không ai nối với lô giao đang rủi ro. Một kho dữ liệu thừa hưởng từng chút của điều đó, vì sao chép dữ liệu mất kết nối vào một kho lớn không kết nối nó; nó tập trung hóa mớ hỗn độn.

Chi phí thứ hai im lặng hơn, trả bằng giờ làm của người bạn. McKinsey, nghiên cứu cách những người lao động tri thức dùng tuần của họ, đã thấy họ mất trung bình 1,8 giờ mỗi ngày — 9,3 giờ mỗi tuần — để tìm và thu thập thông tin. Trên một xưởng đó là production lead đối chiếu sổ đơn hàng với bảng tồn kho, người mua đuổi theo một lead time qua một chuỗi email, người lập kế hoạch dựng lại cùng một bức tranh mỗi sáng vì không có gì giữ nó qua đêm. Dữ liệu phẳng buộc một con người phải săn từng sự thật và ráp lại bức tranh bằng tay; một ontology đã giữ sẵn các kết nối, nên câu trả lời là một truy vấn, không phải một buổi chiều. Định nghĩa đối tượng một lần, nối nó lại, và sự trôi dạt không còn chỗ nào để bắt đầu.

Một ví dụ thực tế: một lần thiếu hàng, hai kiến trúc

Các con số dưới đây mang tính minh họa — một ví dụ sạch, không phải sổ sách của khách hàng — nhưng hình dạng thì đúng y như cái chúng tôi thấy trên các xưởng thật.

Bạn đặt một đơn bán hàng: 1.000 túi Eagle-9 cho Calloway, giao ngày 28. Đây là điều mỗi kiến trúc làm với nó.

Trên một mô hình phẳng

Đơn hàng đi vào sổ đơn hàng như một hàng. Tồn kho sống ở một bảng khác. Bảng định mức vật tư sống trong một file thứ ba mà production lead duy trì. Không gì kết nối chúng, nên khoảnh khắc đặt đơn trôi qua trong im lặng. Hai tuần sau dây chuyền đi lấy ballistic nylon và thấy 1.840 mét tồn kho so với 2.400 mà mẻ chạy cần. Nó dừng lại — freight gấp, tăng ca để bù khoảng hụt, và một cuộc gọi cho Calloway để thương lượng lại một ngày bạn đã hứa. Dữ liệu đã ở đó cả. Chỉ là nó ở ba phòng không nói chuyện với nhau.

Trên một ontology

Đơn hàng là một đối tượng, và khoảnh khắc nó được đặt hệ thống đã biết chuỗi — đơn cần túi Eagle-9, túi này có BOM v3, mà dòng của nó giải về ballistic nylon trong kho. Vậy nên nó làm phép tính mà một bảng tính để lại cho con người: 1.000 × 2,4 m = 2.400 m cần so với 1.840 tồn kho. Thiếu 560 m. Nó đọc thuộc tính lead time — 14 ngày — và bắn cảnh báo ngay ngày đơn được đặt, hai tuần trước khi dây chuyền đâm vào tường. Rồi nó thực hiện một *hành động*: nó mở một nhiệm vụ — *kiểm tra và đặt lại 600 m ballistic nylon, owner: John, cần-trước đã đính kèm* — trong hệ thống John vốn đã làm việc. Toàn bộ quá trình đi xuyên, ngay ngày đặt đơn, kết thúc bằng một nước đi có chủ thay vì một ô đỏ:

```mock

shortage

```

Nylon được đặt vào một ngày bình thường, theo giá niêm yết. Dây chuyền không bao giờ dừng. Calloway không bao giờ nhận cuộc gọi.

Cùng dữ liệu, cùng tuần. Khác biệt duy nhất là liệu đơn hàng, BOM, và tồn kho có thể thấy nhau hay không — và khác biệt đó đáng giá một hóa đơn freight gấp cộng một ca tăng ca, mỗi lần nó xảy ra. Trên một xưởng thật nó xảy ra nhiều hơn bất kỳ ai muốn thừa nhận.

Operational ontology *không phải* là gì

Vì cái từ này bị kéo căng, đây là ranh giới, vẽ thật sắc.

Nó không phải là một kho dữ liệu

Một kho dữ liệu tập trung hóa việc lưu trữ. Một ontology mô hình hóa ý nghĩa và cho phép hành động. Bạn có thể cấp dữ liệu cho một ontology *từ* một kho, nhưng đổ các hàng vào một cái xô lớn không tạo ra các mối quan hệ — và các mối quan hệ mới là sản phẩm.

Nó không phải là "một ERP"

Một ERP là một hệ thống ghi nhận: nó ghi lại cái doanh nghiệp đã làm, sau khi đã làm. Một ontology ngồi *trên* ERP của bạn (và MES, và các bảng tính của bạn), nối những gì đang xảy ra ngay bây giờ xuyên qua tất cả, và biến nó thành một quyết định trước khi tổn thất được ghi sổ. Một bên nhìn lại phía sau; bên kia nhìn về phía trước. ERP ở yên chỗ của nó — ontology nối nó lại, nó không thay thế.

Nó không phải là một dashboard

Một dashboard là một cửa sổ nhìn vào dữ liệu bạn đi tới và hỏi; nó hiện một con số sau khi bạn nghĩ tới việc nhìn. Một ontology theo dõi các mối quan hệ thay bạn, kéo lên cái đang trượt trước khi bạn biết cần kiểm tra — rồi hành động. Một dashboard chờ đợi. Một ontology tới với bạn.

Nó không phải là một knowledge graph để tìm kiếm

Một knowledge graph được nối để *truy xuất* — tìm tài liệu, trả lời câu hỏi — là một họ hàng, nhưng nó chỉ đọc và nó về các sự thật, không phải vận hành. Một operational ontology được dựng để *chạy* một vận hành: nó mang trạng thái sống, logic của doanh nghiệp bạn, và các động từ ghi ngược lại hệ thống thật của bạn. Tìm-và-trả-lời là một tính năng. Hành động trên vận hành mới là công việc.

AI ngồi trên cái này thế nào (và vì sao nó không ngồi được trên mô hình phẳng)

Đây là nơi toàn bộ thứ này tự trả tiền cho chính nó — và là trái tim của lý do vì sao một ontology là hệ điều hành cho quyết định. Chĩa một mô hình AI vào một bản xuất phẳng và nó làm việc trong mù lòa. Nó đọc được các hàng, nhưng không thấy rằng đơn này cần vật liệu kia từ nhà cung cấp hay-trễ này, vì kết nối đó chưa từng được ghi lại — nên nó làm cái mà một hệ thống tự tin không có ngữ cảnh sẽ làm: nó bịa ra cái gì đó nghe có vẻ đúng. Đó là màn trình diễn làm bạn lóa mắt một lần và giúp bạn không bao giờ. Chĩa cùng mô hình đó vào một ontology và nó thừa hưởng cả bản đồ; giờ nó có thể xếp hạng cái thực sự rủi ro trong tuần này, gọi tên owner có thể sửa, và soạn tin nhắn cho nhà cung cấp. Trí tuệ chưa bao giờ chỉ nằm trong mô hình AI — nó nằm trong mô hình đó *cộng với* ngữ cảnh kết nối mà nó được suy luận trên đó. Các mô hình AI cứ ngày càng rẻ và sắc hơn; tài sản khan hiếm là ngữ cảnh chúng chạy trên đó.

Và về người của bạn: hệ thống kéo lên và đề xuất; *con người quyết định.* Nó trao cho quản lý nhà máy của bạn cảnh báo khi vẫn còn thời gian để dùng — nó không cầm lái. Những người vận hành sắc bén nhất của bạn ngừng dành nửa ngày để đối chiếu các con số giữa các hệ thống và dành nó cho những quyết định chỉ họ mới làm được.

Cái này nằm ở đâu trong MIDAS

Phiên bản thực dụng: đây chính xác là cái MIDAS xây. Nó là lớp trí tuệ công nghiệp ngồi trên các hệ thống bạn vốn đã chạy, và operational ontology là lõi của nó — mô hình kết nối của các đối tượng, thuộc tính, mối quan hệ, và hành động của bạn. (Đây là cách nền tảng ráp nó lại trên đầu stack hiện có của bạn.)

Chúng tôi không xây lại hệ thống của bạn — chúng tôi kết nối dữ liệu của bạn và đặt AI lên trên.

ERP của bạn ở lại. Các bảng tính của bạn ở lại. MES của bạn, các công cụ dự án, cảm biến và camera, nơi nhắn tin chứa các cập nhật thật của bạn — tất cả ở lại. Một forward-deployed engineer vẽ ra cách vận hành của bạn thực sự chạy, định nghĩa các đối tượng một lần, đi dây các mối quan hệ mà hôm nay chỉ sống trong đầu đội của bạn, và gắn các hành động ghi ngược lại. Một hệ thống. Một ontology. Không phải nhổ-bỏ-thay-mới, không phải một dự án mười tám tháng. Và vì nó là ứng dụng được cấp ngân sách đầu tiên mà hầu hết người vận hành nhận ra, ontology thường được xây bên dưới một triển khai AI project management — công việc dự án là cái nêm; mô hình kết nối là cái khiến nó thấy được thực tế.

Ontology càng giàu, nó càng sắc, vì mỗi đối tượng bạn nối làm cho mọi đối tượng khác hữu ích hơn. Nối đơn hàng với tồn kho và bạn có cảnh báo thiếu hàng. Thêm dưới xưởng qua Production Intelligence — sản lượng sống, độ trượt, và tín hiệu chất lượng — và bạn thấy nút thắt đang hình thành trước khi nó lan ra. Thêm khách hàng và ngày giao, và một máy chậm lại lúc 2 giờ chiều trở thành một cuộc gọi bạn thực hiện hôm nay thay vì một lời xin lỗi tuần sau. Đó là lợi thế mà vận hành ở bên kia thị trấn không sao chép được bằng cách cố gắng hơn, vì nó sống trong phần đi dây, không phải trong nỗ lực.

Câu hỏi thường gặp

Operational ontology là gì, nói cho dễ hiểu?

Nó là một mô hình kết nối duy nhất của vận hành của bạn, được dựng từ bốn phần: những thứ có thật (đối tượng như đơn hàng, máy, vật liệu), điều bạn biết về mỗi thứ (thuộc tính), cách chúng kết nối (mối quan hệ), và điều bạn có thể làm (hành động). Được giữ trong một bức tranh sống duy nhất thay vì mười file rời rạc, nên phần mềm và AI có thể suy luận xuyên suốt cả vận hành và hành động trên nó.

Operational ontology khác một data model hay cơ sở dữ liệu thế nào?

Một data model phẳng lưu hàng và cột; các mối quan hệ giữa các thứ hoặc sống trong đầu một con người hoặc nằm chôn ở nơi không gì đi qua. Một ontology biến các mối quan hệ thành đối tượng hạng nhất mà hệ thống có thể đi theo — nên nó có thể trả lời "nếu cái này trượt, còn gì hỏng?" rồi hành động. Lưu trữ không giống một quyết định.

Chẳng phải ontology chỉ là một kho dữ liệu với vài bước thừa sao?

Không. Một kho dữ liệu tập trung hóa việc lưu trữ để nhìn lại phía sau — nó có thể cho bạn biết cái gì đã xảy ra, rẻ. Một ontology mô hình hóa ý nghĩa và cho phép hành động: nó nối trạng thái sống xuyên qua các hệ thống của bạn và kéo lên cái sắp hỏng, trước khi tổn thất được ghi sổ. Bạn có thể cấp dữ liệu cho một ontology từ một kho, nhưng sao chép các hàng vào một kho không tạo ra các kết nối — và các kết nối mới là sản phẩm.

Tôi có cần thay ERP hay bảng tính để có một cái không?

Không. Một operational ontology ngồi *trên* các hệ thống bạn vốn đã chạy và nối chúng lại. ERP, MES, công cụ dự án, và bảng tính của bạn vẫn hoạt động đúng như hôm nay; ontology nối những gì đang xảy ra xuyên qua chúng và biến nó thành cảnh báo và hành động. Bạn nối cái đang có — bạn không nhổ nó ra.

Vì sao tôi không thể cứ chĩa AI vào bảng tính và có được điều tương tự?

Vì một mô hình AI suy luận trên cái nó thấy được, và một bản xuất phẳng giấu đi các kết nối. Nó đọc được rằng nylon thấp và một đơn đang tới hạn, nhưng không đọc được rằng *đơn này* cần *nylon kia* từ một nhà cung cấp có lead time 14 ngày — nên nó đoán. Cho cùng mô hình đó một ontology và chuỗi ở ngay đó dưới dạng đối tượng; giờ nó suy luận theo cách người vận hành giỏi nhất của bạn sẽ làm, và đề xuất nước đi thay vì bịa ra một cái.

Mất bao lâu để xây một cái?

Vài tuần, không phải một năm. Bạn không mô hình hóa cả vận hành cùng lúc. Bạn tìm ra quyết định duy nhất tốn nhiều nhất khi nó sai, đi dây hai hoặc ba hệ thống lẽ ra đã bắt được nó, chứng minh cảnh báo bắn ra trước tổn thất, và phát triển ontology từng kết nối một từ một kết quả đang chạy.

Thấy vận hành của bạn được mô hình hóa thành một ontology

Xây lát đầu tiên của một operational ontology là một cuộc trò chuyện, không phải một dự án chuyển đổi. Chúng tôi sẽ vẽ ra một quyết định đang tốn của bạn nhiều nhất, gọi tên các đối tượng và kết nối lẽ ra đã bắt được nó, và cho bạn thấy chính xác những gì cần để đặt cảnh báo trước mặt bạn trước khi tổn thất xảy ra. Đặt một buổi đánh giá lớp trí tuệ.