信息系統(tǒng)項目目標采用動態(tài)控制是監(jiān)理工作的基本方法之一。依照信息化工程監(jiān)理規(guī)范，監(jiān)理工作的順利開展取決于建立一整套完備的監(jiān)理機制，包括監(jiān)理機構、監(jiān)理活動基本流程、文檔管理規(guī)范、溝通機制、問題管理機制等等。
系統(tǒng)項目建設一般分為六個階段，即：項目準備階段、總體設計階段、設計開發(fā)階段、實施階段、驗收階段和運行維護階段。根據(jù)不同項目的特點和具體情況，監(jiān)理介入有早有晚，可能是全過程監(jiān)理，也可能只針對某一個或某幾個階段實施監(jiān)理。
信息系統(tǒng)項目周期可長達兩年、三年，甚至更長。周期越長說明項目越復雜，建設過程中可能出的問題越多。尤其對于一些先天不足的項目(建設過程中并沒有完全遵照信息系統(tǒng)建設的基本客觀規(guī)律)，不可避免地會隨著項目建設的推進，暴露出越來越多的各種問題。
一類型項目的監(jiān)理中，毫無疑問，問題分析、管理和解決機制扮演著重要角色，因為整個項目建設就是在不斷地發(fā)現(xiàn)問題、解決問題的過程中一步一步走向最終目標。監(jiān)理方必須及時了解問題、跟蹤問題的發(fā)展和解決進程，并有義務向系統(tǒng)各方通報現(xiàn)狀和提出監(jiān)理方觀點。監(jiān)理價值也正是在發(fā)現(xiàn)問題、預警風險、促進解決問題的過程中得到充分體現(xiàn)。本文即是充分運用了問題管理的概念和方法,力圖特定項目建立起特定的、有可操作性的問題管理機制。以下通過對發(fā)現(xiàn)問題、分析問題、處理問題等幾個方面的分析探討問題管理機制。
1.問題定義
并不是所有人反應的問題都是真正的問題，監(jiān)理方必須做出一系列判斷。是不是問題？是暫時的問題還是長久的？有多嚴重？比如在我們監(jiān)理過的某個政府信息化項目中，由于更換了開發(fā)商而新開發(fā)了一套軟件，新軟件替換舊軟件上線后不久，用戶方主管部門反應軟件操作不方便導致咨詢電話不斷，甚至某些用戶產(chǎn)生怨言。這算不算問題？通常在軟件重大版本更新很可能發(fā)生使用習慣問題，更何況案例中的軟件開發(fā)商也更換了。因此，用戶的某些不理解和應用習慣未必意味著開發(fā)商的設計問題。
問題定義：問題是項目建設過程中出現(xiàn)的會對系統(tǒng)產(chǎn)生不利影響的故障、變化、和風險的總稱。
2.發(fā)現(xiàn)問題
監(jiān)理方和承建方、用戶方都應該建立規(guī)范、穩(wěn)定的溝通渠道。對于某些特殊的項目監(jiān)理方的客戶和信息系統(tǒng)的用戶可能不是同一個單位，即系統(tǒng)的投資方和用戶方不一致，在這種情況下監(jiān)理方需要建立和三方的溝通渠道。溝通渠道的完備為及時發(fā)現(xiàn)問題打下了基礎，一般來說，問題會通過以下幾種方式反應出來：
* 用戶方通過已建立的溝通渠道直接向監(jiān)理方反應系統(tǒng)問題；
* 承建方通過已建立的溝通渠道直接向監(jiān)理方反應用戶方出現(xiàn)的業(yè)務問題、流程問題、管理問題等；
* 客戶方通過已建立的溝通渠道直接向監(jiān)理方反應系統(tǒng)建設問題；
* 在監(jiān)理會議上各方都可能反應系統(tǒng)建設問題；
* 用戶方向承建方提交系統(tǒng)運行故障單，承建方再抄送監(jiān)理方；
* 監(jiān)理方在工作中主動發(fā)現(xiàn)問題。
3.分析問題
對于信息化工程建設中出現(xiàn)的問題，往往是公說公有理、婆說婆有理。大型信息化工程，特別是涉及若干個不同部門的工程，扯皮推委現(xiàn)象是造成工程延期的重要原因之一。因此監(jiān)理應運而生。人們常說成功的項目七分考管理，監(jiān)理工作也是如此，技術層面的問題和分歧往往更容易解決。作為項目建設第三方，監(jiān)理方既要保持公正、公平、公開的立場，又要建立和維持各方之間友好、一致的工作氛圍。因此，監(jiān)理方除了從技術角度為項目把關，還要充分發(fā)揮管理藝術，這樣才能協(xié)調處理好項目建設各方的關系，更有效率地解決問題，推動項目的進展。
在項目建設中，對于各方反應的問題監(jiān)理方首先必須做出判斷。做出判斷后才可以對問題立項，跟蹤問題的發(fā)展和解決進程。那么是不是我們對待所有問題都一概而論呢？答案顯然是否定的。問題的輕重緩急、問題提出方的態(tài)度、問題對系統(tǒng)影響的大小等因素都決定了監(jiān)理方需要對問題分類處理，采取不同的監(jiān)理策略區(qū)別對待。也只有如此才能面向項目，以達到最大限度地減少分歧、提高整體工作效率、體現(xiàn)監(jiān)理價值。 通常的監(jiān)理項目中的問題可分為四類，如下圖：
根據(jù)上圖，很顯然，A類問題最有可能體現(xiàn)監(jiān)理方價值。這類問題往往涉及到多方關系協(xié)調，因為只涉及到一方的問題大多可以通過該方的內部工作解決。如果問題涉及到多方，只能靠協(xié)調解決。這種時候最常見的消極情況是互不配合、只關注和自己有關的環(huán)節(jié)，扯皮、推卸責任。此時監(jiān)理的一項重要作用得以發(fā)揮，即組織協(xié)調。例如，在我們監(jiān)理的某個投資巨大的電子政務項目中出現(xiàn)了一個問題。 由于相關的業(yè)務流程復雜，環(huán)節(jié)多，涉及到的單位多，協(xié)調困難，誰都不認為自己有問題，甚至出了問題都不知道該向誰反應，結果導致系統(tǒng)的最終服務對象-老百姓的利益受損。僵持了一段時間后，監(jiān)理方意識到了問題的嚴重性。經(jīng)過大量調研，發(fā)現(xiàn)在流程中若干環(huán)節(jié)相對問題集中，而且這幾個環(huán)節(jié)都由一個單位(甲)負責，于是提出問題解決方案，包括詳細的處理流程。
兩個層次，第一層次是：出了問題將直接向甲單位反應，該單位負責協(xié)調相關各方解決問題；第二層次是：成立問題協(xié)調小組，成員包括各單位領導，若有甲單位協(xié)調解決不了的問題向協(xié)調小組匯報，由協(xié)調小組協(xié)調解決。解決問題的機制建立后，對最終用戶來說有了反應問題的場所，各方責任清楚，提高了解決問題的效率，和政府的辦事效率，老百姓的利益得到了保障。后來事實證明只有少數(shù)問題反應到了協(xié)調小組。在這個問題上，監(jiān)理作用得到充分發(fā)揮。
B類問題既然其他各方可以把它解決好，那么此時如果監(jiān)理方再試圖推動的話，會讓其他各方感到多余，甚至更糟的話可能會有干涉對方內部工作的嫌疑。比如在某項目中，用戶方反應承建方對系統(tǒng)故障排查和服務相應的速度太慢，在這個問題上，承建方?jīng)]有異議。事實上，問題的存在是由于他們的其他工作太忙而沒有顧得上及時解決。因此，對于這個問題上，監(jiān)理方在態(tài)度上立場鮮明，支持用戶方的態(tài)度。
C類問題同A類一樣也有可能體現(xiàn)監(jiān)理價值，但不同的是，其他各方?jīng)]有意識到問題的嚴重性，甚至根本沒有注意到問題的存在，這種情況下監(jiān)理方必須立場鮮明地站出來，并指出問題的隱患，這是監(jiān)理的職責所在。例如在某項目中，由于用戶方的需求改動頻繁，而且往往沒有給承建方流出合理的時間，造成承建方疲于應付新需求變動而缺少時間完善系統(tǒng)。 此時監(jiān)理方注意到這個問題是由于缺少規(guī)范的需求管理造成的，于是我們擬訂出管理制度文件并最終促成各方簽署。在監(jiān)理方多次闡明利害關系之后，各方均認識到需求管理流程被規(guī)范后會提高系統(tǒng)建設總體效率，對誰都有好處。
有很多問題在我們初步調研后即發(fā)現(xiàn)它們不影響大局，或者向問題定義一節(jié)中提到的操作適應性等問題，這些問題各方都不關注，也確實不重要，甚至過了一段時間問題的提出者都把這件事忘了。這就是圖中表示的D類問題，這類問題自然不用花費很多精力。
4.問題跟蹤
根據(jù)問題分類原則確定了監(jiān)理方策略后，監(jiān)理方需要跟蹤問題發(fā)展狀況和解決進程。我們的問題跟蹤機制總的思路是：建立《問題列表》，所有問題按某一特定的順序排列，比如提出的時間。每個問題需包括問題編號、提出時間、提出人、描述、重要性級別、解決方案、解決方案批準人、要求解決時間、目前狀態(tài)等信息。而對于某一具體問題，我們建立《XX問題跟蹤表》，目的是記錄問題發(fā)生、發(fā)展、解決整個過程中與問題有關的活動、討論、決議和監(jiān)理方觀點。
表中應該包括問題編號、活動類型、活動日期、決議、監(jiān)理方觀點等信息。這樣做可以為將來撰寫問題報告打好基礎。《XX問題跟蹤表》和《問題列表》通過兩個表中某些共同項目建立映射關系，比如問題編號或問題描述，如果是電子文件可以考慮建立超級鏈接。當然，由問題的重要程度不同，并不是每個具體問題都有必要建立問題跟蹤表。
4.1問題跟蹤流程(如下圖所示)
4.2流程說明
* 根據(jù)《問題跟蹤表》的內容，每周定期更新《問題列表》的當前狀態(tài)；
* 如有新問題產(chǎn)生，問題列表將即時更新，并即時產(chǎn)生該問題的《問題跟蹤表》；
* 跟蹤一般分為兩條線路，即承建方和用戶方，因為每個問題都可能涉及到系統(tǒng)和業(yè)務兩個方面；
* 每個問題一般由兩個人共同跟蹤，分別負責承建方和用戶方兩條線，其中一個是該問題的負責人；
* 針對重點問題跟蹤所獲得的全部信息都及時按時間順序記錄在一個確定的問題跟蹤表中。《問題跟蹤表》和《問題列表》通過兩個表中某些共同項目建立映射關系，比如問題編號或問題描述，如果是電子文件可以考慮建立超級鏈接。
* 由問題負責人即時更新《問題跟蹤表》，并且每周三下午確定時間更新《問題列表》中的相應問題項目；
5.問題報告
問題報告是在問題的某一階段監(jiān)理方對該問題認識的總結，可以是在問題發(fā)現(xiàn)階段、問題解決階段，也可以在問題解決后。問題報告的對象是監(jiān)理方的客戶，在客戶的授權下可以抄送給項目其他相關各方。因此問題報告是監(jiān)理方客戶了解項目進展的重要渠道。
報告的內容應包括對問題的描述，即問題的發(fā)生和發(fā)展過程，信息來源于《問題跟蹤表》，還應包括監(jiān)理方對問題的分析和監(jiān)理方建議。
問題報告是監(jiān)理方客戶了解項目進展的重要渠道，監(jiān)理方應盡量多報告。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.guhuozai8.cn/
本文網(wǎng)址：http://www.guhuozai8.cn/html/support/11121824320.html
相關文章
