Giảm thời gian xử lý sự cố từ 【6,0 ngày xuống 0,8 ngày】 chỉ trong 2 tháng: Học hỏi từ Công ty Cổ phần Matsuri Technologies cách xây dựng một tổ chức phát triển vững mạnh 

Hợp tác phỏng vấn: Ông Satoru Hanada, Trưởng phòng Phát triển, Bộ phận Phát triển, Công ty Cổ phần Matsuri Technologies / Ông Tomoya Oshima, Nhóm SIC

Điểm chính của bài viết này

• Giảm thời gian xử lý xuống còn 1/7 trong vòng 2 tháng (từ 6,0 ngày xuống còn 0,8 ngày)

• Chìa khóa nằm ở quyết định “Trước hết là ghi chép, sau đó mới đến tự động hóa”

• 3 yếu tố góp phần vào thành công: Sự hỗ trợ từ chủ sở hữu sản phẩm, văn hóa “một đội ngũ” và cảm giác khẩn trương do sự thay đổi nhân sự chủ chốt

• Các biện pháp cải tiến: Quản lý kiến thức tập trung vào Notion × Hệ thống AI lấy Datadog MCP làm nòng cốt

• Gợi ý: Chính những bước đi khiêm tốn mới là nguồn gốc của những thay đổi lớn trong tổ chức

Trong loạt bài “Học hỏi từ các doanh nghiệp có khả năng phục hồi: Cách xây dựng tổ chức phát triển vững mạnh” này, chúng tôi sẽ giới thiệu các ví dụ thực tiễn từ những doanh nghiệp đang tiên phong giải quyết các thách thức chung như việc xử lý sự cố phụ thuộc vào cá nhân hay việc phát hiện sự cố dựa vào nhân lực. Mục tiêu của loạt bài là mang đến cho độc giả – những người đang nỗ lực thực hiện cải cách – những kiến thức thực tiễn có thể áp dụng được, thông qua logic ra quyết định và thực tế của quá trình chuyển đổi tổ chức.

Đối tượng được giới thiệu trong kỳ đầu tiên là Công ty Cổ phần matsuri technologies, đơn vị chuyên phát triển và vận hành nền tảng lưu trú và cho thuê ngắn hạn với mô hình vận hành tiết kiệm nhân lực. Với dòng sản phẩm m2m làm nòng cốt, đây là một doanh nghiệp công nghệ đã không ngừng mở rộng quy mô kinh doanh trong suốt 9 năm qua, đồng thời hỗ trợ cả mảng kinh doanh lưu trú của chính công ty lẫn các nền tảng thu hút khách hàng bên ngoài (như Sumyca, Ichiji-koku.com, v.v.).

Chỉ trong vòng 2 tháng, tổ chức phát triển này đã rút ngắn thời gian xử lý yêu cầu từ 6,0 ngày xuống còn 0,8 ngày, tức là chỉ còn khoảng 1/7 so với trước đây.

Yếu tố then chốt không phải là công cụ AI mới nhất hay việc thành lập đội ngũ SRE chuyên trách, mà chính là quyết định cốt lõi : “Trước hết là ghi chép, sau đó mới đến tự động hóa ”. Trong bài viết này, dựa trên cuộc phỏng vấn với ông Hanada, người đứng đầu bộ phận phát triển tại matsuri technologies, và ông Oshima, người đứng đầu đội ngũ SIC, chúng tôi sẽ giới thiệu logic đằng sau quyết định đó cũng như hành trình thay đổi của tổ chức.

Từ trình độ cá nhân đến cơ cấu tổ chức — Matsuri Technologies trước thềm chuyển đổi

Trước khi đi vào câu chuyện về những thành tựu, trước tiên chúng ta hãy cùng điểm qua các đặc điểm kinh doanh và những thách thức của matsuri technologies.

Các sản phẩm đã hoạt động trong suốt 9 năm qua được tích hợp không đồng bộ với các nền tảng đặt phòng trực tuyến (OTA) như Airbnb. Đặc thù kinh doanh là vận hành với ít nhân lực đã khiến các sự cố hệ thống không chỉ đơn thuần là lỗi kỹ thuật, mà còn mang lại cảm giác căng thẳng và trọng trách lớn, bởi chỉ một sự cố hệ thống cũng có thể dẫn đến tình huống “khách không thể vào phòng đêm nay”, từ đó ảnh hưởng trực tiếp đến việc cung cấp dịch vụ và mức độ hài lòng của khách hàng. Hơn nữa, các sản phẩm của matsuri technologies không chỉ được khách hàng bên ngoài sử dụng mà còn được các bộ phận nội bộ công ty sử dụng hàng ngày.Đây là một cấu trúc độc đáo, trong đó người dùng của các kỹ sư bao gồm cả khách hàng bên ngoài lẫn nhân viên nội bộ.

Dựa trên đặc thù của dự án này, tổ chức phát triển đã phải đối mặt với hai thách thức chính.

Vấn đề 1: Tính phụ thuộc vào cá nhân

Hệ thống phát triển của matsuri technologies, nếu truy nguyên nguồn gốc, ban đầu bắt đầu từ mô hình phân công “mỗi người phụ trách một sản phẩm”. Ông Hanada, người đứng đầu đội TS, chia sẻ: “Khi hoạt động kinh doanh mở rộng, chúng tôi nhận ra rằng ‘nếu cứ tiếp tục như thế này, mọi người sẽ không thể nghỉ ngơi được và chắc chắn sẽ gặp khó khăn’. Chính từ bối cảnh đó, chúng tôi đã dần dần chuyển sang mô hình làm việc theo nhóm.”

Sau khi thành lập đội, việc hệ thống hóa kiến thức và tài liệu đã diễn ra một cách đều đặn, nhưng vẫn chưa thể nói là đã đạt đến mức đầy đủ. Tuy nhiên, lý do chúng tôi vẫn có thể xử lý công việc mà không gặp sự cố lớn nào là nhờ kỹ năng của từng kỹ sư đều rất cao.

“Trên thực tế, tại hiện trường, không ít trường hợp xảy ra tình huống rằng ‘càng là hệ thống lâu đời thì càng khó hiểu nếu không được một số thành viên cụ thể xác nhận’”, ông Oshima, người đứng đầu nhóm SIC, nhận xét.

Việc phụ thuộc vào cá nhân là một yếu tố ảnh hưởng đến sự ổn định của tổ chức. Huống chi là tại một công ty như matsuri technologies, nơi dịch vụ và công nghệ được kết hợp với nhau, thì ảnh hưởng đó là không thể lường trước được.

Thách thức thứ hai: Sự phụ thuộc vào nhân lực trong việc phát hiện

Một thách thức về mặt cấu trúc khác là việc phát hiện sự cố phụ thuộc vào nhân lực. Như đã đề cập trước đó, đội ngũ phát triển sản phẩm và các bộ phận kinh doanh – những người dùng sản phẩm – đều nằm trong cùng một công ty, nên thông báo đầu tiên về sự cố thường được gửi từ các bộ phận kinh doanh qua Slack. Sự gần gũi về mặt tổ chức giúp phản ứng ban đầu diễn ra nhanh chóng, nhưng mặt khác, điều này cũng tiềm ẩn rủi ro rằng “nếu các bộ phận kinh doanh không phát hiện ra, sự cố sẽ không được phát hiện”.

“Liệu có phải ở đâu đó đang xảy ra những sự cố mà chúng tôi, đội ngũ phát triển, chưa nhận ra không?” (ông Hanada)

Ông Hanada cho biết những lo lắng như vậy luôn đeo bám đội bóng.

Sự kiện đánh dấu bước ngoặt đối với những thách thức mà chúng tôi đang phải đối mặt chính là việc ông Hanada – nhân vật chủ chốt – được điều chuyển sang một đội khác. Nhận thức rằng “Nếu cứ tiếp tục như thế này, hoạt động kinh doanh sẽ không thể duy trì được nữa” đã khơi dậy ý thức trách nhiệm mạnh mẽ trong toàn bộ tổ chức.

3 yếu tố đã tạo ra sự thay đổi

Không ít tổ chức khi đối mặt với những thách thức như của matsuri technologies đã chọn bắt đầu từ “tự động hóa bằng AI”. Tuy nhiên, matsuri technologies lại quyết định làm ngược lại, quay trở lại những nguyên tắc cơ bản bằng cách “xây dựng hệ thống lưu trữ dữ liệu”.

Ông Oshima, người gia nhập công ty vào năm 2026, đã có một động cơ rất đơn sơ.

“Khi có yêu cầu, chúng tôi thường bắt đầu bằng câu ‘Đây là gì vậy?’. Nếu không hỏi người tiền nhiệm hoặc những người chủ chốt để biết cách xử lý, chúng tôi sẽ không thể tự mình biết được. Chúng tôi nhận thấy đây là một vấn đề, và điểm khởi đầu chính là suy nghĩ: ‘Ít nhất, trước tiên hãy ghi chép lại rõ ràng những việc đã làm!’” (Ông Oshima)

Người ta nói rằng, xuất phát từ suy nghĩ đó, mọi việc đã bắt đầu từ việc thu thập thông tin theo định dạng quy định.

Tuy nhiên, đằng sau “sự lựa chọn tự nhiên” này là văn hóa doanh nghiệp đã hỗ trợ cho nó. Dù là tại văn phòng thực tế hay văn phòng ảo, văn hóa “một bàn” – nơi mọi người lập tức tập trung lại khi gặp khó khăn – đã tồn tại từ lâu. Lần này, chúng tôi đã áp dụng văn hóa này vào việc xử lý sự cố.

Sự hỗ trợ từ phía tổ chức cũng là một yếu tố quan trọng giúp các sáng kiến chưa từng có tiền lệ này trở thành thông lệ. Đặc biệt, thái độ của chủ sở hữu sản phẩm đã đóng vai trò rất lớn.

Thông thường, với áp lực từ phía kinh doanh, người quản lý sản phẩm thường có xu hướng yêu cầu các thành viên “vừa thực hiện công việc của mình vừa tham gia dự án”. Tuy nhiên, tại matsuri technologies, mọi việc lại không diễn ra như vậy.

“Chủ sở hữu sản phẩm của chúng tôi đã nói rằng trong việc điều tra và xử lý sự cố, có một người chỉ cần đứng quan sát cũng không sao. Ông ấy mong muốn toàn đội cùng nhau giải quyết những vấn đề phức tạp. Trong bối cảnh có những chủ sở hữu sản phẩm khác lại yêu cầu mỗi người phải đảm nhận nhiệm vụ của mình, tôi nghĩ đây thực sự là một sự ủng hộ rất lớn” (Ông Oshima)

Đây là phương pháp được gọi là “swarming”, trong đó toàn bộ thành viên trong nhóm cùng tập trung vào nhiệm vụ được ưu tiên hàng đầu.

Sự hỗ trợ có hệ thống từ chủ sở hữu sản phẩm, văn hóa doanh nghiệp “một đội ngũ thống nhất”, cùng với cảm giác cấp bách trước việc các nhân sự chủ chốt được điều chuyển. Ba yếu tố này kết hợp với nhau đã biến nỗ lực kiên trì “bắt đầu từ việc ghi chép” thành một làn sóng thay đổi lớn đối với đội ngũ và tổ chức.

Cách xây dựng nền tảng vận hành nhằm giải quyết các thách thức — Quản lý tri thức và hệ thống AI

Để giải quyết những thách thức đang gặp phải, chúng tôi đã triển khai các biện pháp xoay quanh hai trục chính. Một là quản lý kiến thức và tài liệu, và hai là các công cụ AI và tự động hóa.

Quản lý và vận hành kiến thức với Notion làm trung tâm

Chúng tôi đã tổng hợp các kết quả điều tra vốn trước đây nằm rải rác ở nhiều nơi như Slack, Google Docs, Notion… vào một cơ sở dữ liệu duy nhất. Ông Oshima giải thích: “Chúng tôi đã tạo ra một hệ thống ngay từ đầu để người dùng có thể nắm được kết quả điều tra về một sự cố cụ thể chỉ bằng cách xem trang này”. Tất cả các yêu cầu đều được lập phiếu trên Notion, đồng thời tổng hợp quản lý thông tin tóm tắt, nội dung xử lý và lịch sử điều tra tại một nơi.

Các biện pháp nhằm đảm bảo tính nhất quán cũng rất cụ thể. Chúng tôi đã tận dụng tính năng mẫu (template) của Notion để chuẩn bị các biểu mẫu sẵn có. Bằng cách khuyến khích nhập các trường thông tin bắt buộc và thiết kế sao cho định dạng luôn nhất quán, chúng tôi đã chuẩn hóa thông tin từ dữ liệu được tích lũy. Đối với việc thu thập thông tin yêu cầu, một số đội đã tiên phong triển khai các trợ lý AI tự động như Claude Cowork; quá trình này đã tiến triển đến mức “tự động thu thập các yêu cầu trên Slack và lưu trữ vào Notion mà không cần sự can thiệp của con người”.

Nền tảng của thiết kế này là ý tưởng: “Khi nhận được cùng một yêu cầu, chúng tôi muốn có thể tham khảo các trường hợp trước đây để xử lý ngay lập tức”. Ông Oshima bổ sung: “Trong tương lai, tôi sẽ rất vui nếu AI có thể tự động xử lý các yêu cầu này dựa trên thông tin này”.

Hệ thống AI và tự động hóa

Điều đã thay đổi cách thức phát hiện sự cố – vốn trước đây phụ thuộc vào các yêu cầu từ các bộ phận kinh doanh – chính là quy trình AI phát hiện và xử lý sự cố.

Trước đây, tại Matsuri Technologies, chúng tôi đã sử dụng riêng rẽ các công cụ như công cụ giám sát hệ thống “Datadog”, tác nhân AI tự động “Devin” và các trợ lý phát triển AI “Claude Code” và “Codex”; tuy nhiên, với sự ra đời của Datadog MCP, chúng tôi đã có thể tích hợp các công cụ này và sử dụng chúng như một quy trình phát hiện sự cố.

Datadog MCP là một cầu nối giúp truyền các thông tin nhật ký và lỗi trong Datadog sang AI và các công cụ khác; dưới đây là các đường ống AI tận dụng chức năng này.

Trước tiên, Devin – một tác nhân AI tự động – sẽ tự động kiểm tra nhật ký lỗi của Datadog theo định kỳ. Chúng tôi đã thiết lập hệ thống để khi phát hiện sự cố, hệ thống sẽ tự động tạo phiếu báo cáo trên GitHub Issue (nơi ghi lại các tác vụ phát triển). Hơn nữa, bằng cách xây dựng cơ chế cho phép AI đưa ra đề xuất khắc phục, chúng tôi đã thiết lập một quy trình liền mạch, từ khâu phát hiện đến đề xuất giải pháp mà không cần sự can thiệp của con người.

Tuy nhiên, tính năng phát hiện tự động vẫn chưa được triển khai trên tất cả các sản phẩm, và có vẻ như họ vẫn đang tiếp tục thử nghiệm và điều chỉnh để chuẩn bị cho việc triển khai chính thức.

Trong quá trình điều tra khi xảy ra sự cố, các công cụ như Claude Code và Codex đang được sử dụng; theo hướng sẽ truyền trực tiếp nhật ký và thông tin APM đến hệ thống AI thông qua Datadog MCP để đẩy nhanh quá trình thu hẹp nguyên nhân.

Nghe nói những ý tưởng thực tiễn này nảy sinh một cách tự nhiên từ “buổi trao đổi” diễn ra hàng ngày vào lúc 3 giờ chiều. Nhờ có cơ chế chia sẻ lẫn nhau về các công cụ mới thử nghiệm gần đây và những kiến thức đã học được, chu trình tích hợp các công cụ mới vào công việc đang diễn ra thường xuyên.

Thời gian thực hiện giảm từ 6,0 ngày xuống còn 0,8 ngày. Điều đã biến mất chính là “thời gian chờ” trước khi bắt đầu công việc.

Thời gian xử lý yêu cầu (từ khi lập phiếu đến khi hoàn tất) có giá trị trung vị là 6,0 ngày vào tháng 2 năm 2026, ngay sau khi áp dụng phương pháp phân công nhiệm vụ và làm việc theo nhóm. Con số này đã giảm xuống còn1,0 ngày vào tháng 3 và 0,8 ngày vào tháng 4. Đây là một sự cải thiện đáng kể, chỉ trong vòng 2 tháng, thời gian xử lý đã giảm xuống còn khoảng 1/7 so với mức ban đầu.

Ông Hanada đã phân tích cơ chế ẩn sau những con số như sau.

“Trước đây, có xu hướng kiểu như ‘Thôi thì cứ lập phiếu trước đã, việc còn lại để sau’. Nhưng giờ đây, mọi người đã chuyển sang suy nghĩ ‘Đã lập phiếu rồi thì cứ làm ngay đi’, và tôi cho rằng đây chính là sự thay đổi lớn” (ông Hanada)

Khi ông Hanada kiểm tra lại dữ liệu về thời gian xử lý trong quá khứ (từ khi bắt đầu đến khi hoàn thành), ông đã phát hiện ra những điều sau đây.

“Thực ra, về thời gian xử lý từ khi bắt đầu đến khi hoàn thành, cả giá trị trung bình lẫn giá trị trung vị trước đây và hiện nay đều không có nhiều thay đổi. Trước đây, đặc điểm nổi bật là ‘biên độ dao động của thời gian xử lý khá lớn’, nhưng nhờ đợt cải tiến lần này, sự dao động đó đã được khắc phục. Tình trạng công việc thường bị ứ đọng do không rõ ai sẽ phụ trách đã không còn nữa, và công việc hiện đang được tiến hành với nhịp độ ổn định” (ông Hanada)

Cả trong quá khứ lẫn hiện tại, thời gian xử lý trung bình vẫn là khoảng 1 ngày. Nói cách khác, tốc độ xử lý kỹ thuật không có sự thay đổi đáng kể, mà dường như thời gian chờ từ khi lập phiếu đến khi bắt đầu xử lý đã được cải thiện.

Và yếu tố quan trọng dẫn đến bước nhảy vọt ngoạn mục vào tháng 3 chính là một nỗ lực khác của chủ sở hữu sản phẩm.

“Khi nhận được yêu cầu, người phụ trách sản phẩm đã đề xuất: ‘Dù chỉ là 30 phút hay một khoảng thời gian ngắn nào đó cũng được, trước tiên hãy bắt tay vào và thử suy nghĩ xem sao’. Nếu giải quyết được thì thật tuyệt vời, còn nếu không được thì sẽ hỏi ý kiến những người có kiến thức. Tôi cho rằng thông điệp ‘đừng cố gánh vác quá nhiều’ này đã dẫn đến những thay đổi lớn vào tháng 3” (Ông Oshima)

Nhờ việc lập phiếu theo cách đơn giản và kiên trì vào tháng 2, các loại và xu hướng yêu cầu đã được thể hiện rõ ràng, và điều này trùng hợp với “đề xuất 30 phút”.

Sự thay đổi trong nhận thức mà ông Hanada đề cập – “Vì đã được đưa vào chương trình nghị sự rồi thì hãy nhanh chóng tiến hành đi” – dường như không phải là kết quả của một quá trình đơn lẻ.

• Tất cả các yêu cầu đã được hiển thị dưới dạng nhiệm vụ trên Notion

• Trong văn hóa làm việc theo nhóm, chúng tôi đã có thể nhanh chóng sẵn sàng hành động với tư cách là một đội

• Nhờ đề xuất kéo dài 30 phút của chủ sở hữu sản phẩm, rào cản để bắt tay vào thực hiện nhiệm vụ đã được giảm bớt

Chỉ khi những yếu tố này kết hợp với nhau, văn hóa ứng phó tức thì — từ việc lập biên bản đến triển khai ngay lập tức — mới bắt đầu hình thành.

　Ông Oshima nhận xét rằng khi ý thức về “an toàn tâm lý” – tức là “không cần phải gánh vác mọi việc một mình” – đã trở nên phổ biến, các thành viên mới cũng có thể tham gia giải quyết công việc ngay từ sớm. Môi trường cho phép tham khảo các trường hợp đã xảy ra trước đây được lưu trữ trên Notion đang giúp đẩy nhanh quá trình biến nhân viên mới thành nhân lực hiệu quả, đồng thời mang lại những thay đổi đáng kể về mặt chất lượng.

3 hướng đi tiếp theo — Mở rộng theo chiều ngang và tăng cường hợp tác với bên ngoài

Mặc dù Matsuri Technologies đã rút ngắn thời gian xử lý xuống còn 1/7 chỉ trong 2 tháng, nhưng tầm nhìn của công ty này đã hướng tới giai đoạn tiếp theo.

Điểm thứ nhất là việc mở rộng phạm vi áp dụng các cải cách.

Dự án này ban đầu được triển khai bởi đội SIC (lĩnh vực quản lý bất động sản và thu hút khách hàng), nhưng trong tương lai, chúng tôi dự định mở rộng sang đội TS (lĩnh vực vệ sinh và làm thủ tục nhận phòng), nơi hình thức làm việc không đồng bộ là chủ đạo. Việc điều chỉnh phương pháp triển khai sao cho phù hợp với đặc thù của từng đội sẽ là thách thức tiếp theo của chúng tôi.

Thứ hai là việc thiết lập các tiêu chí đánh giá mức độ nghiêm trọng.

Chính vì có mối quan hệ gần gũi với các bộ phận kinh doanh, thay vì thiết lập các tiêu chuẩn rập khuôn, chúng ta cần có cách tiếp cận thận trọng, tôn trọng đặc thù và tính đa dạng của từng sản phẩm. Ông Hanada đã chia sẻ như sau:

“Hiện vẫn chưa có tiêu chuẩn thống nhất nào về cách đánh giá dựa trên cả hai yếu tố là mức độ nghiêm trọng và tác động. Trong bối cảnh vòng đời của các sản phẩm khác nhau, liệu có nên ép buộc áp dụng một tiêu chuẩn chung hay không, hay liệu có những điểm chung nào đó? Tôi cho rằng sẽ có những điều dần dần trở nên rõ ràng hơn trong quá trình phát triển và mở rộng kinh doanh.” (Ông Hanada)

Nói cách khác, ông Hanada cho rằng câu trả lời đúng cho các tiêu chí đánh giá không phải là kết quả của việc thiết kế trên giấy, mà là điều tự nhiên hình thành từ thực tiễn hàng ngày và sự phát triển của doanh nghiệp.

Thứ ba là việc tăng cường sự liên kết với các dịch vụ bên ngoài.

Mặc dù việc tích hợp với các dịch vụ bên ngoài như OTA là lĩnh vực mà công ty không thể kiểm soát hoàn toàn, nhưng matsuri technologies không coi đó là một “thách thức”.

“Tôi cho rằng điều quan trọng là không nên gạt bỏ các sự cố xảy ra trên dịch vụ bên ngoài với lý do đó là do nguyên nhân bên ngoài, mà cần có thái độ cùng nhau phát triển. Nếu chúng tôi chia sẻ những sự cố mà công ty chúng tôi phát hiện được với đối tác, đối tác cũng sẽ tích lũy được kiến thức và việc phối hợp phát hiện tự động sẽ được đẩy mạnh. Thay vì đổ lỗi cho đối tác về sự cố, tôi cho rằng chúng ta cần có thái độ thúc đẩy sự trưởng thành của toàn ngành” (Ông Hanada)

SIGQ Insight — Học hỏi từ các trường hợp thực tế: Xây dựng cơ chế ghi chép và tự động hóa

Từ trường hợp của matsuri technologies, chúng ta có thể thấy một cấu trúc phổ quát, đó là chỉ khi đã hoàn thiện “hệ thống ghi chép” trước tiên thì mới có thể đo lường được hiệu quả của việc tự động hóa.

Theo kết quả cuộc khảo sát do SIGQ thực hiện với 250 nhà lãnh đạo VPoE, EM và SRE, trong số các tổ chức đã triển khai cải cách quy trình xử lý sự cố, tỷ lệ trả lời rằng “không có cải thiện” đã lên tới 32,4%. Trong bối cảnh nhiều tổ chức dù đã bắt tay vào thực hiện nhưng vẫn không đạt được kết quả như mong đợi, những trường hợp như matsuri technologies – nơi triển khai theo trình tự “ghi chép → tự động hóa” – mang lại nhiều gợi ý quý báu cho toàn ngành.

Đây là những điểm trọng tâm trong các hoạt động sắp tới mà ông Hanada đã nêu ra

• Các nhóm chưa thống nhất với nhau về mức độ nghiêm trọng của sự cố

• Chúng tôi muốn tự động hóa việc phân loại và đánh giá mức độ nghiêm trọng của nhật ký lỗi

Hai vấn đề này cũng là những thách thức chung mà nhiều doanh nghiệp phải đối mặt.

Đối với những tổ chức như matsuri technologies, vốn đã xây dựng nền tảng cho việc “ghi chép”, hai vấn đề này chính là những thách thức tiếp theo mà họ phải đối mặt. Chúng tôi tại SIGQ cũng đã thiết kế Incident Lake xuất phát từ cùng nhận thức về vấn đề này.

Incident Lake do SIGQ cung cấp sử dụng trí tuệ nhân tạo (AI) được huấn luyện dựa trên lịch sử xử lý các sự cố trước đây để tự động đánh giá mức độ nghiêm trọng và đề xuất các giải pháp từ các trường hợp tương tự cho các sự cố đang diễn ra theo thời gian thực. Với thiết kế này, bằng cách kết hợp với lịch sử điều tra được lưu trữ trên các nền tảng như Notion, hệ thống có thể tự động liên kết các “bản ghi” mà matsuri technologies đã xây dựng với “các biện pháp ứng phó ban đầu tiếp theo”.

Gửi đến các độc giả cùng chia sẻ mối quan tâm này. Hành trình của matsuri technologies cho chúng ta thấy rằng, cải cách không bắt đầu từ những công cụ tiên tiến nhất, mà từ một bước đi khiêm tốn là “trước tiên hãy ghi chép lại ”. Một mẫu Notion, việc áp dụng văn hóa “swarming”, hay sự động viên từ Product Owner với câu “Chỉ cần 30 phút là được” — tất cả đều là những hành động mà bạn có thể thử áp dụng ngay từ hôm nay trong tổ chức của mình. Chắc chắn rằng, tổ chức của bạn cũng có “bước đi đầu tiên” của riêng mình.

Phỏng vấn và viết bài: Takashi Kamoda, chuyên gia của Công ty Cổ phần BtoB