軟體公司是不是應該是使用者經驗分享的組織者？

本篇文章版權由ECF和HP所有

軟體公司雖然常常以教授的身份對待他們的客戶，但是自身的知識管理體系卻差強人意，面向客戶的知識轉移往往還是取決於顧問或者精英的水平和意願。

軟體中通常蘊藏了許多管理思想，內建了很多邏輯，研發環節的知識積累到實施環節散佚很多，實施顧問更難結合企業實際業務去充分利用“隱藏”的邏輯；對於使用者來說，遇到問題首先找軟體原因是沒錯的，這是一個路徑。但是我們都習慣於從技術角度，認為軟體可以“削足適履”，可以開發。實際上需要從軟體的應用環境，前後和相關業務的關聯去思考，去變通，許多問題都可以藉此解決，或者在經歷過這個考察過程後，問題不復存在了（認知之後，問題就不存在了，是說我們看到了新的問題點、價值點，問題被替代了）。最近看到河南二建對資訊化程式中發現問題、解決問題的方法和路徑，確實值得我們借鑑和學習。他們首先從系統的引數設定、流程配置這些方面去找差異，大部分情況下找到了解決問題的第三條道路。但是如果將這些問題提交給軟體公司，往往要消耗掉極其多的顧問資源，更長的週期以及不菲的費用。這是為什麼呢？

軟體公司是不是應該收集此類問題，直接分享給該款軟體的其他使用者及實施人員？一款軟體具體模組的研發意圖和應用場景的匹配應該有不少差異，這些差異在經歷過成百上千個專案之後，往往已經形成了可觀的資料庫，可惜是非結構化的，無法充分分享。這些資料一部分來自於顧問，更多的來自於資深的使用者。

軟體公司是不是應該是經驗分享的組織者呢？ 

本篇文章版權由ECF和HP所有