清查公司系統紀錄中！責任的釐清！？改善工作執行制度！？

新主管、新政策、新方法...
針對系統的部份總算要來個有力的清查作業
但....很可惜的是...只是局部性的檢討

樂觀的點想，也許現在從我這邊清查和建立系統log的追蹤和責任釐清的相關工作方法和制度
可以影響和改善其他單位使用系統時候的態度...

但悲觀一點呢...本來使用就亂七八糟的系統，之後會更亂七八糟
只是....垃圾積在誰家罷了∼

至於現在的狀況呢？後者囉∼當然....希望只是陣痛期

之前使用這類系統，不管是客服紀錄或是Bug紀錄
被追蹤和解決這件事情...
其實想到最貼切的事情，就是家裡到處塞的雜物
常用的自然常常用，帳單不交會被斷水斷電，自然你會處理掉帳單
但如果是....電器的保證書∼朋友的喜帖∼遊戲的說明書∼旅遊展蒐集的DM∼雜誌....廣告....
這類的小物呢？
套句電視上的收納大師講的話「如果雜物放在角落三個月，你都沒去碰∼那這輩子你都不會需要那個東西，請丟了吧∼」

公司系統上的紀錄，也可以套用這樣的說法...
很多人說沒紀錄就沒人追啊？
現在是雞生蛋、蛋生雞的問題了∼
追了就有人解嗎？有紀錄就會有人追嗎？解的都有紀錄嗎？
（瘋掉的笑）

轉錄：如何撰寫建議書

建議書是無言的銷售人員，它能代替銷售人員同時對不同的對象銷售，突破了時間與空間的限制；它是銷售過程的全面彙總，也是客戶取捨評斷的依據。

建議書的準備技巧

　　撰寫建議書前，您先要準備好撰寫建議書的資料，這些資料是您從銷售準備開始時就應留意的，因此，建議書的資料取自於銷售準備、詢問調查、展示說明等各個過程，，您在這些銷售過程對客戶的瞭解及對客戶的影響，是建議書成敗的主要因素。

　　撰寫建議書前要收集哪些資料呢？

　　把握客戶現狀的資料：

　　例如保險業的經紀人要知道客戶的資料有：

　　·目前參加了那些保險；

　　·年齡；

　　·家庭人口數；

　　·小孩的年齡；

　　·職業狀況；

　　·收入狀況；

　　·身體狀況。

　　正確分析出客戶感覺到的問題點或想要進行的改善點：

　　找出客戶對現狀感到不滿的地方，若您的銷售對象是企業，可以收集各個使用人員對現狀的意見。

　　知道了客戶對現狀的不滿意點，銷售人員就能進行構想出改善的方法。

　　競爭者的狀況把握：

　　您要掌握住競爭者介入的狀況及競爭者可能帶給客戶的優缺點、提供客戶的各項交易條件等，獲得競爭者的情報，您在做建議書時就能抵消競爭者的銷售對策，凸顯自己的優勢，協助客戶做正確的選擇。

　　瞭解客戶企業的採購程序：

　　銷售人員瞭解客戶企業的採購程序，才能知道建議書的傳遞對象，同時能把握住建議書是否在對方編制預算前即需要提出，以獲得預算的編制。

　　瞭解客戶的決定習慣：

　　有些客戶做購買決定時，習慣收集很詳細的資料，鉅細糜遺。有些客戶習慣於重點式資料，而要求銷售人員到場對建議書說明。因此事先瞭解客戶購買決定的習慣，您能做出合於客戶味口型式的建議書。

建議書的撰寫技巧

　　建議書的撰寫技巧能幫助您達成建議書的目的，建議書是一個溝通的媒介，它最終的目的是希望獲得訂單。

　　如何能讓客戶看了您的建議書後馬上籤約呢？您要能滿足兩個條件：

　　1、讓客戶感到滿足

　　讓客戶感受到需求能被滿足，問題能夠得到解決。

　　客戶花錢進行購買行為時，一定是對現狀不滿或想要改善現狀，當客戶心裡有了這種想法，正在摸索進行時，若是您能即時地提供客戶一套適合於解決客戶問題的建議案，無異於幫了客戶的大忙。

　　如何才能提出上面這種建議案呢？關鍵點在建議書的準備技巧中所提的——要能正確地分析客戶的問題點。

　　2、與關鍵人物的溝通

　　您還要與承辦人、承辦單位主管、使用人、預算控制部門、關鍵人士能做有效溝通。

　　一份建議書不一定會完全經過這五種人過目，此處我們以這五種人做例子，提醒您撰寫建議書時如何和這些對象做有效的溝通。

　　承辦人：

　 　負責承辦的人是代表企業和您溝通的第一線人員，他扮演的角色往往要能替您向企業的上級人員解釋說明產品的特性、效用、能改善多少問題、能提升多少效 率……等，因此，以承辦人的立場，對各項細節都希望能獲得充分的信息。所以您撰寫建議書時，對各個細節部分要嚴密，不得有破綻，可用附件的方式補充說明， 務必要讓承辦人能回答上級可能提出的問題。

　　承辦單位主管：

　 　承辦單位的主管，多半對瑣碎的細節無暇過目，並且以主管的立場而言，他對結果較注意，至於導出結果的原由細節，他是授權給承辦人員去審核。因此，建議書 中的「主旨」「目的」「結論」是承辦單位主管關心的重點。您在撰寫建議書時的「主旨」「目的地」「結論」要能滿足承辦單位主管的需求。

　　使用人：

　　對使用人而言，建議書撰寫的重點是針對使用人提出的現狀問題點及希望改善的地方，詳細地說明採用新的產品後能解決他們的問題。

預算控制部門：

　　預算控制部門人員關心的重點是費用預估，是否合於預算。因此，關於費用部份，您在撰寫建議書時，務必清楚明確地寫清各項費用狀況，並以清楚地報表彙總各明細，讓他們能一目瞭然。

　　關鍵人士

　　關鍵人士關心的重點有兩項，一為效用，另一為優先順序。

　　關鍵人士位處企業的高層，他的判斷點多為產生的效用對企業的營運有哪些幫助。例如您的產品對增加銷售人員的業績有幫助，關鍵人士將能認同這種效用。

　　另外，優先順序也是關鍵人士判斷的重點，因為關鍵人士是從企業全盤的角度思考事情，他往往面臨的不是單一事件，因此，他會權衡完全不相干的兩件事情，而做出執行上的優先順序，因而，若銷售人員疏忽了這方面的考慮，往往被關鍵人士判定暫緩而前功盡棄。

　　若您撰寫建議書時能技巧地滿足上面的兩個條件，相信您的建議書一定具有強烈地說服力，能稱職的扮演無言銷售人員的角色。

　　3、把握競爭者的狀況

　　您要掌握住競爭者介入的狀況及競爭者可能帶給客戶的優缺點、提供客戶的各項交易條件等，獲得競爭者的情報，您在做建議書時就能抵消競爭者的銷售對策，凸顯自己的優勢，協助客戶做正確的選擇。

　　4、瞭解客戶的採購程序

　　銷售人員瞭解客戶企業的採購程序，才能知道建議書的傳遞對象，同時能把握住建議書是否需要趕在編列預算前提出，以獲得預算的編制。

　　5、瞭解客戶的決定習慣

　　有些客戶做購買決定時，習慣收集很詳細的資料，鉅細糜遺。有些客戶習慣於重點式資料，而要求銷售人員到場對建議書說明。因此事先瞭解客戶購買決定的習慣，您能做出合於客戶味口型式的建議書。

　　6、建議改善對策

　　您的對策要能針對問題點的原因進行改善，並能清楚地讓客戶理解，同時還要有具體的資料證明您的對策是可行的。

　　7、比較使用前及使用後之差異

　　在建議書中，您要比較使用前（現狀）及使用後（建議案）的差別，比較時要提出具體的證明，如目前每日產出1000單位，自動化後每日產出1500單位，對購買決定有影響的有利點及不利點都要進行比較，以便客戶能客觀地判斷產生的差異。不過，要注意的一點是：比較時僅提出結果比較，詳細原因部份可以用附件做說明。

　　8、成本效益分析

　　建議書的成本計算要正確合理，效益包括有形的效益及無形的效益，有形的效益最好能數值化。效益必須是客戶也能認定的。

　　9、結論

　　結論是彙總提供客戶的特殊利益及效益，結論要能要求訂單。

　　10、附件

　　附件要容易查詢，每一個附件都要有標題和頁碼。

　　雖然不是所有的產品都需要使用到建議書，但若您銷售的產品是附加價值較高、可改善客戶的效率或能解決客戶的問題，此時，建議書是不可缺少的銷售利器。

　　建議書是利用文字的組合進行銷售，建議書的邏輯架構及表達陳列的方式，能顯現出您是否夠專業，學習建議書的撰寫技巧是讓閱讀建議書的客戶感受到您專業，而更能認同您的建議。

　　記住撰寫建議書時，隨時提醒自己：

　　·潛在客戶為什麼要接受我的建議書？

　　·還有哪些點能幫助客戶做迅速、正確的決定？

全文來源：http://blog.xmfish.com/index.php/uid-305894-action-viewspace-itemid-33639

筆記：軟體品質協會論壇文章。何謂軟體可靠度？

請問何謂軟體可靠度 ? 與硬體可靠度有何差別 ?
應依據何種標準發展與測試 ?
是否需納入 FCA 與 PCA ?
應如何在需求文件中展述有關軟體可靠度的需求 ?
應如何在設計文件中展述有關軟體可靠度的 Traceability ?

因此，個人就不揣淺陋，簡單表達個人意見如下：

首先，我們要瞭解可靠度是產品眾多品質屬性中的一項，它屬於產品的非功能性需求。所以要瞭解可靠度就如同要瞭解其它的需求一樣要「由上往下」的去思考，才能掌握其要義。

吾 人之所以需要一件產品或一個系統，就是要它來協助我們處理某一事務或問題，也就是產品就是我賴以處理問題的工具。然而天下任何東西都不完美的，都有其極 限，都有其可能失效的時候，而我們使用的工具亦然。當我們想要使用它時，若它不能為我們所用，那麼我們必然會蒙受損失。所以於經營管理上，我們有必要於使 用工具前瞭解其可靠的程度。此一可靠程度的表達方式，在以往硬體為主的情況下，通常用以下三個數字來表達。

1. 平均失效時間MTTF(mean time to failure)
2. 平均修復時間MTTR(meat time to repair)
3. 可用性(Availability) = MTTF / (MTTF + MTTR) x 100%

因 為有了這樣的數據，我們才能進一步決定，再其失效時間內，我們要如何處理我們原有的問題？如果有替代的方式處理時，它的成本為何？如果沒有替代方式處理時 所造成的損失為何？我們有沒有可能再提昇產品的可用性？可提高至何種程度？其成本又為何？…諸如此類的問題，只有再有了可靠度的相關數據後，才有可能做出 有根據的理性決定。

在硬體的世界中，產品之所以會失效(撇開設計與製造的因素)，主要有兩大原因，一為磨損，一為材料疲勞，都是自然界物 理特性所使然。所以，在硬體系統的領域常使用兩個(或以上)相同的元件互為備援，來提昇系統的可靠度。譬如：系統原本的可靠度為70%，若同時使用個原本 的系統互為備援作為一個新的系統。那麼這個新系統的可靠度就可提昇到 91% ( 1- (1 - 70%) x (1 - 70%))。

然 而在軟體的領域中，沒有磨損與材料疲勞的問題。造成軟體不能如預期般的運轉，是因為需求規格(SRS)、設計說明(SDD)或程式中有缺陷(fault) (或bug)。並於使用時程式執行時遇到了這些缺陷，才使得軟體失效(failure)。因此，不同的使用者對相同的軟體，可能對該軟體的可靠度有完全不 同的感受。另外，軟體提抍可靠度的方式與硬體也截然不同。在對軟體可靠度有嚴苛的要求環境中(通常是要藉由軟體可靠度確保產品的安全性)，譬如：飛航管制 系統…等，經常再不容出錯的地方以相同的需求規格，不同設計的模組，做平行的運算，只有當兩組(或更多)模組結果相同時，才往下繼續執行其它的步驟。否 則，將不執行這些步驟。藉此來確保軟體的可靠度與安全性。

有了以上的基本認識，現在來看軟體可靠度的定義。有人將它定義成：the probability of a software system to perform its specified functions correctly over a long period of time or for different input sets under the usage environments similar to that of its target customers. 於分析軟體可靠度時，要準備 operation profiles 作為模擬客戶使用的輸入資料(個人認為這是在執行上比較困難的部份)。也要於數種可靠度模型(model)中選用一種，以做為分析軟體可靠度的方法。有關 可靠度模型，我不完全瞭解，也就不多做介紹了。

現在，先就可靠度本身做一個總結，後面再對衍生的問題加以說明。可靠度是對產品的一項品質 屬性所做的客觀描述，只要它是依照與客戶所約定的方式進行，分析的過程也沒有錯誤的話，不論其最後的數字高或低，可靠度本身都不會有問題。可靠度有沒有達 到目標或要求，以及如何達到可靠度目標才是問題。不過這個問題，不是可靠度分析可以處理的。另外，可靠度也不能協助我們定位某一次失效的原因，當然也就不 能用它來判斷，出問題的是硬體或軟體。

至於，應依據何種標準發展與測試 ?個人不知道。

另外，FCA(產品的功能型態稽 核 / Functional Configuration Audit)是確保受稽核的軟體項目與它的規格一致。PCA(實體型態稽核 / Physical Configuration Audit)是確保設計與參考文件和建置出來的軟體產品實體是一致的。因此，從其目的上來看兩者都與可靠度似乎是沒有關連的。

應如何在需求文件中展述有關軟體可靠度的需求？我想這最主要要看開發團隊執行軟體可靠度分析的能力，以及與客戶協商的結果(採用什麼樣的可靠度模式)而定。

最後有關可靠度的 Traceability 的問題，個人以為與管理其它需求規格的追溯方式沒有什麼不同。

希望以上的說明，能對各位有所幫助。

周茂松 敬上

原文網址：http://www.csqa.org.tw/portal/modules/newbb/viewtopic.php?topic_id=388&forum=1&post_id=976#forumpost976