嚴先生
對我來說，這是個代名詞，這是我唯一叫的出名字的旅館經營者。 所以這是給所有旅館經營者的。
不知道您所經營的旅館，商務客佔它總營收的多少？
身為一個不是太經常住旅館的人（尤其是住台灣的旅館）。
對於飯店，我一直有個疑問。
你們知道商務客在房間最常使用的地方是哪裡嗎？
除了床之外，是書桌。
書桌就是我們的辦公室。
但是，我在住旅館的時候，通常只能選擇趴在床上辦公。
因為書桌椅，它根本就不是設計來給人使用的。
那個椅子，不管它有多貴，或是有多美，我沒辦法坐在它上面超過一個鐘頭，更別奢望是『舒服的』坐在椅子上。
而相對應的，那個書桌。是的，它很氣派，但您有嘗試在那張書桌上去使用筆記型電腦嗎？
插座在哪？ 燈在哪？桌子搭配椅子後得高度？燈的亮度？
我很能體會這些房間的設計是為了『舒服的休息』。
但是，不能同時具備『舒服的工作』這樣的理念嗎？
如果有一間飯店，它可以同時滿足這兩個要素，我相信，它的顧客回籠率會比別的同業更高。
直到所有的同業都模仿了為止。
一個微不足道的商務旅客
目標：透明化新車車價，把售車點變成試車跟交車點。把業務變成客服。
方法：實名制
調查項目
品牌 型號 配件 贈品 營業所 業務人名 成交金額
金額接受廠商以發票更正
兩個方法
第一種 實體交易 記憶中 CTCB有在做了
當merchant端進行刷卡動作時，CPS就發一組動態密碼給持卡人的手機。然後持卡人再把密碼輸入到pin pad。交易才完成。
第二種 無實體交易 台灣好像沒人作
無實體merchant，刷卡動作為持卡人經由手機輸入以下資料：
卡號
CVV
TPIN
merchant代號
消費金額
把這些資料發送給CPS，CPS回覆交易序號及驗證碼給持卡人，再由持卡人將交易序號及驗證碼送給商店。
先寫標題
數量級的不同
台灣的系統跟大陸的系統，其中最大的差異，就是數量級的不同
就我本身參與規劃的系統來說。
台灣的核心銀行，目標客戶數600萬到800萬，很多了。但這在大陸只是一個中小型的省的數量，更別說是直管市了，那會上億。
所以相同的系統，相同的功能，從台灣搬過去就能用的？ 除非剛好是地方級。不然，像我客戶那樣，光客戶數就破億，要作系統大集中。有誰能確保自己設計的系統撐得住？
這時候 系統架構的強固性跟彈性的價值才會彰顯出來。
一個客戶端連線會消耗系統多少資源？
沒有做分散式規劃的話，一台機器能撐多少同時的連線？這麼大的機器，客戶願不願意買？
有做分散式處理的話，頻寬要多少？網點要怎樣分佈？整個伺服器群的規劃？資料的即時性？
會有千奇百怪的問題冒出來，這樣，你手上產品的價值還剩多少？要小修、大修還是重翻？
不修不改能給多少人用？留多久的資料？留多少的資料？
修修改改又能吃多少？
重寫，重翻，你有多少成本？客戶付你多少錢？你還剩什麼價值？
這些，不是我們在台灣隨隨便便用一台PC搞定幾百個concurrent connection的時候能夠想像的！
機器是n台，架構的好，管的好的話它的複雜度可能一直都是1，普通一點的是n，而更常見的是n^2。
PM，SA，Arch，DBA這些人都具有規劃得出這樣數量級系統的能力嗎？
就還不用說使用者需求，文化，法律等等的差異了。
待續
產出物： 電訪名單
產出格式： Fixed Length, csv, xls
產生方法： 依照指定的週期，指定的格式，在指定客戶名單中的資料欄位以及電訪結果作調配
其他功能： 電訪結果匯入、電訪結果輸入、名單匯入、名單輸入
很小的大系統
很大的小系統
目前有個客戶每天用來調配千萬筆的客戶名單跟算億的通話結果。
是的，大陸的客戶。
話說 FNS的core banking他的設計架構是以CIF為中心。
所有個產品、額度、關係人、擔保品，都圍繞著CIF。
但是外圍系統不是這樣幹啊。
所以，以相同的觀點來看事情：
既然所有跟核心帳務相關的東西都要先開CIF。
那以下的系統都可以重新設計，以客戶CIF為中心。
閱讀全文…
現在的銀行
對於放貸部份
消金 企金 是分開的
而貸款戶跟帳戶又是分開的
如果有 互相擔保
甚至是 企金的集團戶
總額度是多少 用了多少
各級額度限制是多少 用了多少 可不可以平調 或是母公司向下調
各幣種的限額又是多少
如果同時有多個loan account要開立，佔用額度的時候會不會相互衝突或是沒有占到？
閱讀全文…
又是2000年之前的事情。
當時國內大部分的專業Call Center都是使用Nortel Symposium以及Avaya Definity系列的交換機。
而這兩套交換機，都有提供狀態抓取功能。
當時Nortel因為已經是Symposium時代，所以有提供API，還不算難寫。
而Avaya，他的官方說法是要透過CMS，乖乖隆地咚，要很多錢，所以客戶請我繞後門。這個後門，還比Nortel的API好寫，哈。
總之，就這樣
閱讀全文…
最近買了一個GSM MODEM來作簡訊收送的『玩具』
在努力研究文件幾個鐘頭後，把PDU發送簡訊的部份寫完了。
研究文件期間，有一個感想。
制定規格的人不是天才就是白癡，省資料傳輸空間省到一個令人厭惡。
要感謝賣我MODEM的人，要不是他附的DLL需要註冊，我還不會想要去寫程式，寫AT COMMAND，K文件。
寫了一個下午，最大的感想是，果然太久沒寫程式，一直要查HELP，沒HELP一定死人。
把這套系統Open Source會不會擋人財路呢？
再說吧，先把收簡訊的部份寫完再說。
閱讀全文…
首先，要感謝很多人，我大哥的朋友們，海基會，香港中國旅行社林經理。
其次，這篇文章，不為什麼，只為了讓日後有相同狀況需要處理的朋友，有個準備的依據。
最後，最後，這是獻給我大哥的文章，願他安息。
閱讀全文…