幫助台/票務系統類別樹的最佳實踐
曾經配置過幫助台/票務系統的人是否曾經經歷過圍繞創建“正確”票證類別的相同迭代過程？
修訂版 1：
基礎設施
伺服器
- 思傑
- 視窗伺服器
- …
桌面
- 視窗
- 蘋果
- …
應用
應用程序 1
- 問題
- 要求
應用程序 2
…
使用者
- 重設密碼
- 被鎖在外面
- …
一切似乎都很好，直到您意識到您在每個公司站點都具有上述功能，因此您嘗試將站點指示器放入層次結構中，一切似乎又恢復了。然後你會想到，大老闆會想知道所有基礎設施票的總和，但由於你有 16 個不同的基礎設施桶 - 每個站點一個 - 你不能輕易回答這個問題。等等，等等等等。
根本問題是我們試圖使用靜態層次結構來建模本質上是多維的東西。問題不僅僅是對數據進行切片和切塊。層次結構越“完整”，服務台分析師就越難以正確分類每張工單（“這是一個伺服器，但它在紐約辦公室，所以它屬於伺服器還是紐約？”）同樣的問題存在於關係數據庫中，因此最終創建了多維數據集。它存在於部落格文章中，因此最終您可以使用多個類別標記文章。標記是答案，但大多數票務跟踪產品不支持這個概念，所以我們回到靜態層次結構。
鑑於此，我有興趣了解人們如何設計他們的類別層次結構，以便在保持相關性的同時盡可能廣泛，同時不讓分析師的生活變得困難。
謝謝
當你說問題是你試圖只使用一個類別欄位來編碼本質上是多維的東西時，你是完全正確的。您需要其他維度的附加欄位。
我們使用 IssueTrak，它具有可用的標準類別層次結構。但它也有一個單獨的位置欄位，因此您可以按位置或按類別或兩者進行報告和統計。還有其他欄位可以為您的特定站點打開或關閉。例如，您可以根據需要將位置匯總到區域中，並根據需要將它們稱為與位置和區域不同的名稱。如果您想使用部門，您可以打開這些部門。有組織。例如，有資產項目，因此您可以將工單與 Server01 相關聯，並且 Server01 可以有自己的一組您可以報告的特徵。
同樣，我認為嘗試將各種維度編碼為層次結構是錯誤的。在我看來，您可能需要針對您可能想要報告的各種類型的事情使用單獨的欄位。