By Euta , 8 November 2007

企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一...企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一.

嚴謹的方法論會定義資訊工作流程中,每階段應參與的角色與該角色所應進行的工作.這些定義與現行企業日常工作會有以下差異:
1. 與現有工作流程不同,亦或新增工作流程
2. 新增角色或角色定義不同
3. 新增工作產出

筆者碰過最麻煩的就是為了調配角色與工作流程,而必須進行組織改造與變革.以公家機關而言,新增的角色涉及相關組織章程的變動,因此以簡馭繁的方式通常是一人兼多職,最後的結果就是流於形式,不了了之.以民營企業而言,除涉及人事成本增加,另外最麻煩的就是權力的分配.通常這就是一般顧問案無法取得一致共識的原因之一.

By henry , 8 November 2007

應用系統還是在繼續運轉,功能合於需求,也未達無法調整及擴充的地步。但是因硬體的停產影響,而必須作更換,算起來所需支付的費用也不少。就成本效益而言無法提出有力的說法....

By F I N , 8 November 2007

「創意」這種東西很奇妙、許多人都有這種感覺、在小學階段台灣人比美國人聰明、在中學階段兩者就差距不大、到了大學階段美國人就比台灣人有創意多了、這可能是生理特性或是文化教育特性....

By henry , 7 November 2007

似乎在每一個新系統導入後,檢討聲及哀號聲會延續一段時間,這個現象在有記憶中一直重覆的出現,差別只是各家的混亂狀況持續的時間長短而已...

By Euta , 24 October 2007

關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答...建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要...關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答.

其實建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要.

資訊架構方法特別對於資訊架構決定文件有特別的描述.其中一項重要的內容就是必須將討論過程與決定的原因詳細紀錄於資訊架構決定文件中.或許有些人會覺得為何要花時間紀錄這些枝微末節?大家開了那麼多會來討論,不是已經有共識了嗎?

筆者曾於數年前參與一項新專案評估規劃,當時以為很快就可以拍板定案,接著馬上開工執行.沒想到因為種種原因,甲乙雙方都數度更換專案小組內的成員,使規劃時間一直延長.這時馬上就暴露了沒有資訊架構決定文件的風險.因為新成員並未參與之前的討論,因此對於建議書內所使用的技術與架構有不同的看法.因為規劃過程拖延太久,人員又變動,因此對於當初如何決議採用這些技術的過程,已經無法交代清楚.因此該案最後在新成員彼此的意見無法整合的情況便胎死腹中.

若是當初有把討論的過程詳加紀錄,讓後續成員能理解當初設計的架構為何?後來這草案是如何因應需求的修改,以及預算時間等因素的考量而變更,他們便可以理解整個故事的來龍去脈.撇開政治因素以外,其他應該尊重原來專案人員的決定,這樣規劃過程應該可以更順利.

不曉得各位是否也曾有此經驗?

By F I N , 19 October 2007

方法論只教你設計的「方法」、並不會教你設計的「內容」。
偏偏有經驗的設計者、說實在的、並不信賴別人的「方法」、寧願相信自己的「做法」....

By Euta , 18 October 2007

方法論在台灣一直不被重視,我的初淺看法是五千年來的民族性使然,無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與.... 關於方法論這檔事,小弟實在是一位菜鳥,因此不敢提出什麼長篇大論.不過關於這個主題,我是非常有興趣,因此希望能在此先拋磚引玉,引起大家討論的興致.

先就方法論本身在台灣一直不被重視這件事,我的初淺看法是五千年來的民族性使然,這應該是無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與,因此通常只要詢問周遭三五好友的意見即可,而且通常這樣一個事件歷時不長,會在短時間結束.比如大部分的人在買車或買房子時,會將所中意的標的物以類似招標工程的方式去分析,這樣的人大概少之又少.

畢竟牽涉的人少,就不需太多溝通協調.歷時短,就不會有太多的變化與意外.因此在方法論裡所強調的文件紀錄,流程控管就顯得多此一舉.但奇怪的是,買股票都會做什麼技術分析,產業分析,然後才買個一兩張,對於房子車子這麼大金額的資產卻很少用科學的方法去分析如何買,怎麼買,買什麼.可見這就是天性.因此若是以這種方法來管理一個登陸月球的專案,我想應該是永遠都不會發射成功的吧?

By Arthur , 17 October 2007

流著 CTO 血液的戰將看得很開:隨時背著行囊,等待下一個明君,前往下一個戰場。可以這麼說:CTO 的美麗揮灑植基於其哀愁的本質;而CTO 的哀愁結局幻化自其美麗的烈焰....CTO 因著他的特殊角色而有其淒愴的宿命

拙作<企業需要 CTO 嗎?>曾論及什麼樣的企業才會需要 CTO
(變動成長迅速、前瞻、志向遠大的企業)
又於<CTO 的適格性>一文談及理想的 CTO 應具備的特質
(興趣廣、學習強、無偏私、通雙語、懂門道)
綜觀之,可說
CTO 的美麗揮灑植基於其哀愁的本質,而
CTO 的哀愁結局幻化自其美麗的烈焰

金控的整併,企業的轉型、躍進
都是產生策略家、創意總監型態 CTO 角色戲份的絕佳舞台