關於Biometrics Authentication 的想法

科技改變世界，沒有人會反對這句說話吧。在過去十數年，我們也親身經歷了一系列的改變，本篇先寫Biometrics Authentication。

Apple 是其中一個將Biometrics Authentication 帶入我們生活的中堅分子（也是牽頭分子吧）。自從iPhone 5S 開始使用 Finger Scan，又自從iPhone X 開始使用 Facial Recognition，成為了我們今日在用的Touch ID 和Face ID。

相較起傳統密碼，筆者認為 Biometrics Authentication 是相較安全的，尤其是在互聯網年代。今時今日，各行各業也推動線上化，線上化平台就少不了牽涉密碼登錄，要記著這許多密碼真的很有難度，不少人就唯有寫下來儲存在其它人接觸不到的地方，但這卻暴露了更多的風險，而且有時type-in 密碼的時候，還要小心旁邊有人偷看，Biometrics Authentication則把一切都簡化了。

現在大部份需要Login 的App 也基本上support biometrics authentication，牽涉金錢交易的銀行當然support，尤其是牽涉高風險交易更要重新驗證，有些中型企業也開始使用。事實上，Apple 的developer guideline 中特別提到authentication 一項，協助開發人員standardize 用戶體驗，現在不少的開發架構平台也使這方面的開發更加容易。

近年也留意到有機構把 biometrics authentication 與實體服務連結，例如銀行ATM 提款，可以經App進行 authentication 再經NFC / QR code 對接ATM，不用再用ATM card 加密碼提款，減少了因ATM卡被複製。另外，早前到新加坡旅行也能在酒店使用NFC unlock 房門，免除了實體房卡，也免除了因違失房卡而致的損失。

不過要留意的是Biometrics Authentication 跟Identification 不同，Biometrics Authentication 是在現有客戶上應用，但新客戶在系統上未有紀錄，不能用作辨識客戶。最近得知政府原有計劃今年推行免費數碼個人身份 (eID)，筆者未有時間詳細了解詳情，但也已十分期待，希望eID可以協助進行認證個人身份之用，免除大量不必要的面對面接觸，也可處理偽冒簽署的問題。

辦公軟件介紹 - WPS

筆者一向是Microsoft Office 的Fans，不算忠實，但早前介紹的One Note 及Skype for Business 都是很好用的辦公室軟件，不過今次介紹的金山辦公軟件WPS，卻是Microsoft Office 的勁敵。

最近開始使用WPS，確實有點驚喜。初次用的時候其實感覺是不太好的，因為WPS的UI介面，基本上跟Microsoft Office 365 的Word、Excel、Powerpoint 無異，感覺就像很多內地產品一樣，直接抄，抄到不禁會想，為什麼金山作為一間上市公司，竟然沒有被控告侵權。。

在網上找了一些資料，大意是說一些二三十前的故事，以及Microsoft 與金山的前世今生。筆者未及fact check，不能確認真偽，但也可相信兩間公司確有就底層的資料格式進行共享，因而兩套軟件基本上可以是互通的（用Mac Numbers開Excel 就會肯定知道他們不是同一個族群）。

不過撇除UI之外，可以看出WPS 的底層架構是比Microsoft Office做得更加精準而且light-weight的。Microsoft 三大軟件，任何一個也在800MB之上，而WPS 只有不夠 300MB，而WPS一個software 就已經可以操控Word、Excel、PPT及PDF，無論是軟件的size 及開啟的速度，都已經可以看出開發團隊的精細工藝。

另外，WPS 的基礎介面上方有tab bar，就像Web Browser 上方那種，這背後的意義是WPS可以一個instance 開啟多個文件，相比Microsoft Office 每份文件為獨立instance 所虛耗的運算，這是極大的優點（經常要開十多二十份文件就可以看到分別）。同時WPS也可以把文件分工作區，讓用家可以按工作需要把開啟的文件歸類。

而與Microsoft Office 365 一樣，WPS 也支援跨平台操作，包括Windows、Mac、iOS、Android，當然亦有Web 版本，不過操控感就不及thick client。另外，雲端共享當然也是必備的。

在現時疫情底下，加速了企業在雲端共享及支持在家辦公的需求，對這些互聯網公司的業務就有極大的推動作用。當然Microsoft Office 在辦公軟件始終有其領導地位，產品銷售亦有更可靠的配套支援，這些領先的優勢是不會輕易被取代的。但看著WPS的快速成長，真心希望Microsoft 也繼續優化，合力推動互聯網產業的推進。

關於「去現金化」的想法

「去現金化」是個人其中一個很想寫的題目，由開立網誌時就已經一直放在待辦清單上，今日終於排到這個題目。

亞洲的國家/地區在「去現金化」方面整體是走得比較前的，香港在這方面進展也很快。今時今日，「去現金化」在香港不是什麼新鮮事物了，就算不說大多數的商戶都已接受信用卡交易，多種電子錢包例如PayMe、WeChat Pay、Alipay、O!e Pay，也是逐漸盛行，加上智能電話上連接信用卡，可以說我們在「去現金化」上，已再進一步進展至「去實體卡化」。

這裏也要提一下金管局早幾年推出的FPS，在金融基建上跨出了極為重要的一步。透過FPS，本地銀行及電子錢包之間建起了即時轉賬的通道，打破了多年以來跨行轉賬的收費及延誤問題，零售及個人層面的使用變得極其方便，這方面較之亞洲其它的地方也是行前一步，即使與內地相比，內地WeChat與Alipay 也未能互通，FPS的出現絕對是值得我們感到自豪的。

事實上，香港在金融層面多年的發展，讓我們有條件可以在這方面發展得很快。首先是本地銀行都已推行電子信息化多年，一般銀行服務的電子化，証券投資電子化，讓行內累積了多年經驗，再加上法規及銀行業界守則的enforcement，大眾都習慣並且能夠放心使用電子渠道處理金錢交易。

不過從另一些角度看，香港在「去現金化」也還有很多不足之處，多年來為人詬病，筆者個人認為八達通和稅務上的漏洞是兩個極為重要的阻力。

先說八達通，八達通也是十多年前香港引以為傲的產物，最先出現取代了現金交易，而且也是世界上最早發展的電子貨幣。一張八達通可以搭乘所有交通工具，可以在大量商戶用來購物。但八達通的最大缺點是安全問題，遺失八達通卡等於遺失上面所有金錢。以前這種缺憾還可以接受，在今時今日沒有authentication 就可以進行交易是絕不能接受的，早就應該要由新的產品取代。另一方面，八達通對商戶不是即時到賬，而且收費也是不低的，除了月費外還要就交易金額收佣，對小商戶來說就像吸血一般。但現實反而是因為八達通的普及和零售層面的壟斷地位，以至一直未被取代。退而求其次，八達通被限制了只能綁定信用卡及容許相對較低的金額上限，不容綁定銀行戶口，而小商戶則寧願繼續用現金也不願被八達通公司剝削。八達通的保留，讓香港的「去現金化」進程停留在差不多二十年前的思維，嚴重阻礙了新技術的發展。

個人認為FPS 的出現，是很有希望可以解決這個問題的。首先FPS 是即時到賬，免除了小商戶現金流的問題，另外可能因為是使用銀行的基建吧，有金管局把關，銀行之間也有競爭，手續費相對上也較低，這不單是相對八達通而言，就算對Visa/Master 卡也便宜得多。

而最重要是銀行與FPS 真正處理了安全問題，所有交易都需要authenticate 才可進行，這在交易金額上就容許了更大的發展空間。而且FPS 容許不受平台不受地域限制，基本上有對方的電話號碼就可以轉賬給對方。而現時FPS在推進發展的QR code 功能，更加方便個人對商戶的遙距轉賬，相信亦可以創造更多應用use case例如即時提供的網上服務。

中長期而言，相信FPS 將可以在基建層面協助大幅度推進「去現金化」。從整體策略角度，商戶所節省了的信用卡手續費，免被外國機構提取，亦可保留在本地推動本地經濟，可謂一舉多得。期望各銀行在技術發展更成熟時，將免費服務由個人層面推廣至小型商戶，將會對「去現金化」有更進一步的推動作用。如果未來個人電話號碼或電郵也能實名化的話，相信對交易雙方也會更有保障。

關於Robotics Process Automation (RPA) 的介紹和想法

傳統上，在機構內的系統要實現流程化或自動化，一般需要透過流程平台對接各個業務平台，而各業務平台亦需要提供API 接口供對接，實作做法在早前需求分析入門系列的「流程化」及「自動化」篇章亦有介紹過。

要比較有效地進行這種形式的系統對接，首先要考慮業務平台本身是否容易建立接口，這會影響項目的成本。一些系統本身設計如較合乎SOA原則，可復用的模塊較多，一般由說也較容易建API，相反另一些系統把 GUI 跟背後邏輯 closely coupled，則比較難建API，或者建立後的後續維護成本也高。

另一個考慮的因素則是系統本身是自家開發還是由外部廠商購置，這亦牽涉成本。鑑於接口可能只適合個別機構內部情況，廠商的產品一般也並不願意做太多非原廠的接口。

面對以上的情況，有些機構會改為考慮使用RPA 工具代替系統對接。RPA的原理是透過紀錄用戶在介面上的動作，然後在介面上直接重覆進行這些動作。基於GUI是業務系統本身已經提供，而且過程亦是直接紀錄用戶的動作，因此可用性不成問題，動作sequence 的可信性也高。如果小時候打機有用過「按鍵精靈」的話，對RPA 就應該不會陌生，一般來說就算不懂programming，只要有邏輯思維亦應能建起較簡單的應用。

當然，RPA的開發，包括紀錄動作、測試、除錯等，還是有一定的成本的。在機構的層面，我們並不會簡單紀錄一套動作然後只重播一套動作，更加會考慮在執行之中加入邏輯，從而能夠復用整套workflow sequence，處理多項同一類別而相類似的工序。

以目前RPA的發展，這些Robots 能夠做到的工作也是頗多的，基本上只要source data 本身是 standardize或者有既定format，RPA 能夠在當中抽取到需要的數據進行邏輯判斷，已經可以讓Robots去做這些工作。當然從成本角度，我們會先選擇重覆性高的工序改為自動化，但可以說在可見的將來，基本上不會再需要有人去處理重覆性或只需要簡單邏輯判斷的工序。

這裏也要提一下RPA 在scalability 方面的優勢，特別是在偶發性出現的大規模處理需求時，RPA 的orchestrator 有條件調用更多機械人同步處理不同的需求。基於工序流程化及重覆，即時調用的機械人按照pre-programmed 的邏輯即可完成工作，對比人工處理就有更大優勢了。

現時RPA 發展更趨向於加入學習模式，就是通常與RPA 合併在一起談論的Machine Learning、AI、Big Data 等，這當然會是科技發展的趨勢，機械人會更多的代替進行重覆性的工序，而我們則更加會轉移向需要更多精細思考，或者靈活隨機而變的工作。但正如早前在「自動化」篇章中提到，進行「自動化」除了考慮工作本身正常運作，更要考慮exceptional handling。

與此同時，在思維上也千萬別以為系統自動化後就與人無關，RPA還是需要有人負責維護管理，並且檢視成效的（正如團隊內有不同人工作，但主管也承擔著責任一般）。有這樣的思維RPA才可以持續發展，真正成為幫助人的工具而不是制造新問題的負累。

生產力軟件介紹 - Zoom

早幾星期在「即時通訊軟件」的篇章介紹過Skype for Business 及騰訊會議，本篇再詳細介紹另一個近期很hit 的通訊軟件，就是Zoom。

和Skype for Business 很相似的，Zoom也是可以提供即時通訊服務的軟件，功能上支援音頻，視頻，文字通訊，亦支援分享desktop，比較特別是支持會議錄音/錄影。最有驚喜的是Zoom還支持iPhone/iPad可透過WIFI Airplay 接駁電腦share screen，對從事iOS App 開發的團隊做demo 就甚為有用。

Zoom 的另外一個優勢地方，是發起會議的簡便。進行會議只需要發起人登記開戶，其它參與者提供會議ID或輸入名稱就可以進入，免除了多餘的登記/登入程序，體驗上差不多就跟打電話一般方面。

而從渠道層面，Zoom 提供Mac、Windows PC 安裝版本，亦有iOS、Android App版，用戶介面都做得極為出色，介面簡潔，一望就知如何使用。而且Zoom 的速度很快，用過會知道它的體驗比Skype 和騰訊會議都要流暢，在行動網絡進行分享桌面更是高下立見。

再望望有些公司仍然使用例如HKT提供的 Tele-Conference Bridge，每次開會主席要點人數，問誰已經參加，這些方案應該快要被淘汰。

今次在疫情之下，Zoom的免費版本由原先只支援10人變為100人，可謂踏出了重要的一步，即時成為企業內部使用的新貴。對於很多企業，尤其是中小企業，可能從來沒有接觸過這些收費軟件，甚至有聽聞過，但也未必會考慮使用。疫情之下催生了work from home需求，而這亦為通訊軟件創造了必要使用的條件。 Zoom 今次搶閘成功，在環球股市狂跌之下股價仍然企穩，再次證明互聯網時代 SaaS 的無限商機。

後記：在Zoom的marketplace 裏發現Zoom與互聯網公司都有合作關係，當中不少也是初創公司，看起來Zoom也是一個極容易擴展及對接的平台。有這樣一個建立 community 的能力，就更難怪它比其它軟件平台成功了。

「信息化」系列 - 論排隊

在香港這個地方，地小人多，排隊是慣常動作。無論是平日餐廳食飯，午飯也好晚飯也好，去超級市場，去銀行，去醫院看病，總之是去到那裏也要排隊。

在服務性行業主導的香港，排隊還是有必要的。提供服務本身需要人力資源，想像一下沒有需要排隊，很有機會代表大部份的服務也是閒置狀態，成本一定會提高。

當然，如果技術上可以支援，服務本身亦可以在網上提供的話，排隊本身是沒有必要的。各行各業都應該借今次機會，檢視服務是否必定要實體店經營。上周在「SOA應用」篇章介紹了virtual queueing room 軟件，專門針對網上短時間內大幅度出現的排隊需求，對於網購平台突然開售搶手物品就大有幫助。本篇則主要針對實體的排隊。

以餐飲業處理排隊的方案為例，香港本地較出名的排隊App 應為「The Gulu」，與不少食肆也有合作，可讓食客遙距取票，內地較出名的則有「美味不用等」及「大眾點評」。這些App 在於為食客節省實際排隊時間，排隊的時間可以用作其它用途，同時避免餐廳門口充塞過多人流（當然有些餐飲營業者會認為排長龍是招徠客人的方法）。在這段抗疫期間，「The Gulu」亦與其它非餐飲小店的合作，協助小店提供服務，很值得支持。

不過另一邊廂以醫院為例，則會見到發展是相當地慢，尤其是公立醫院。絕大多數醫院的排隊至今為止仍然是到院取號，公立醫院門診等候時間更是漫長。這個問題跟食肆不同，停留在醫院過長時間，是會暴露於感染其它呼吸道傳染病的機會，造成不必要風險。而除了門診，就算是預約看症，也會因為之前的看症時間太長而要等候。

以現今科技而言，實在有太多方法可以讓這個流程做得更好，遙距取號也好，實時顯示當前人流也好，可以給求診者更多資訊作出判斷。而即使是預約看症，醫院亦可憑當前隊列判斷可能的延誤時間，就可以減少求診者待在醫院裏的時間。

Blockchain 應用

上周寫了Blockchain 的介紹，本周試寫一下Blockchain 的應用。

在金融領域上，目前Blockchain 在發展的應用包括了國際匯款、信用証、當然也包括了虛擬貨幣，這些應用也圍繞著「跨境付款」。早前聽人說，今時今日不少的基礎金融產品如跨境匯票，是起源自十一世紀十字軍東征，筆者未有時間考究，唯我們常用的SWIFT payment network，則是差不多五十年前開始建立發展的。

說SWIFT network 壟斷了全球的financial transaction 並不為過。自SWIFT成立發展至今，SWIFT message已成為各類型financial transaction message format的標準，全球大部份的大額金融交易都通過SWIFT network 進行。與此同時，SWIFT 建立自家交易平台 SWIFTNet，成為金融機構之間 payment order 一個最可靠的傳輸渠道，並從中收取手續費。

以現今的科技看SWIFT，會感覺這雖然還是一個可靠的渠道，但卻是一個效率很低的系統，而且交易費用亦不便宜。金融交易從Originating Bank 到Beneficiary Bank，中間可能需要經過多間Intermediate Bank及Correspondent Bank，每經過一間就收一次手續費。與此同時，不是每一間銀行都能夠自動處理交易，這令到整筆交易的傳輸速度因為牽涉人工操作而延誤。更壞之處，是payment order 出去之後甚難trace 到當前狀態，或要發另一個swift message 出去trace，又產生另一筆交易手續費用。

這裏要特別一提的是，SWIFT financial transaction 本身並不牽涉 Fund Transfer，它處理的只是Payment Order，交易雙方本身需要在對方銀行也有清算戶口，而匯款交易只是系統上數額的調撥，但全球銀行就需要花不少人力物力在這個基建上。在數十年前這個模式可能是對的，基於金融市場內操作需要假設雙方互不可信任，但在今時今日，是否應該有更好的金融基建協助資金流動呢？

Blockchain 可以在這方面嘗試作出突破，透過全球金融機構的共建平台，可以省去中介平台，減低成本之餘，亦可快速完成交易。有人說Blockchain 的技術問題例如擴展性限制了其發展，這確是急需解決的問題。現時SWIFT 的每日交易量約三千萬，但較常用的Bitcoin交易目前亦只在大約每月一千萬，還差很遠。可能Blockchain 最終也不是完全取代SWIFT，而是作為另一渠道選項，例如專門處理區域內的交易，參與對手數量就可大大減低。

不過目前全球仍然在發展新技術當中，最終結果如何，哪個平台模式較受歡迎，甚至將來是否仍需要清算戶口也並不好說，但可以肯定是，不少市場參與者也明白現有基建的問題，正想辦法搭建更適合這一代的新平台，當中也有不少有央行參與的項目，務求在更有效率快速處理交易之上，維持現有的AML/CFT 標準。

SOA 應用

早前在寫Microservices時提到SOA，今次介紹一個最近留意到的SOA案例，又是與疫情有關。

在疫情之下，不少醫療用品缺貨，當中口罩是重點缺貨物品。對於網上開售口罩的網站，不少也承受不起突如其來的訪問需求，這在Cloud Computing 的篇章也提過。

對於全新的平台以cloud-native architecture來開發，整體在雲端上架設當然好，把大量的infrastructure 管理工作用雲解決。但現有平台有太多不能容易上雲的dependency，不能單單因為個別的問題而要整體改變。今次介紹的是一個來自丹麥，叫做"Queue-it"的service platform，某程度上可以處理這個問題。

據Queue-it 官方網站的介紹，它是一個one-product software technology company，做的就只是一個產品，就是virtual queueing room，能夠為網購平台或其它票務平台提供排隊的服務，當網站負荷超出上限就re-direct 到Queue-it 的排隊室。而對於網購平台，在搭建的時候可以按既定需求建立，但對於前端排隊的模塊，則使用外部提供的獨立服務處理，不需要整體改造或align用同一平台，這正是SOA 的理念，容許各個部份獨立開發及優化，大家透過互聯網互通。

Queue-it 透過SOA讓用戶在是否全面搬上雲端上取得了平衡，這裏其實也應用了Software-as-a-Service (SaaS)的理念，Queue-it 本身也是一整套的軟體平台，但對外部應用來說，它是把整套平台abstract 成為可調用的service，協助網購平台處理了硬件伺服器瓶頸的問題。與此同時，Queue-it 亦有助處理機械人搶購的問題。

筆者最先留意到Queue-it 是太太在口罩工廠Mask Factory 網站所見，後來發現原來較大的平台如百佳、屈臣氏及國泰也有使用。這種商業模式透過subscription 及用量計費，專門做一個service 可以做得更加精益求精。在互聯網世界，這種模式將會日益普及，我們的思維模式也會隨之而變得更加flexible。

生產力軟件介紹 - Airtable

今次介紹另一個筆者很喜愛的軟件，叫做Airtable。

按其名稱可以初步想像，Airtable 的基礎是Database 中的Table，Air則代表可以自由網上存取，不過千萬不要以為是Access Database 的線上版，它的功能可絕不止此。

最初認識 Airtable，主要是它的資料管理非常方便好用，可以協助管理各類型資料，加入相關attribute，尤其適合整理資料做分析。而且Airtable 的基礎雖然是Database，但它的Table就做到可以簡單地以spreadsheet形式展示，做得極為 user-interactive。

Airtable 本身是為沒有coding 背景的人而設，簡單的SQL也並不需要，Database的操作介面本身就已極為方便，例如Table 本身的擴展，Format 改變，基本上只是在UI上改就可以，同時它又可以提供一些spreadsheet 的功能，例如excel formula，vlookup 等，所以就算沒有Database concept，只要懂得用Excel，也可以很容易上手。而Airtable 支援的format極之多樣化，當中例如可以加attachment，dropdown field 可以選擇多項，比較有趣的還可以input barcode （mobile version 可以scan barcode來輸入）。

對有基礎Relational Database 認識的人來說，就可以更深入地理解Airtable的用法，例如使用Airtable 來建立Database，一個Database 上有多個table，互相建立關連，更大範圍的管理數據。跟Database 一樣，Table 上的每個attribute 都需要設定format，比較特別是有些常用的資料類型例如Email，URL，一般Database 未必會有特定format，需要在輸入時加validation，還有對資料管理很有用的如創建日期，最後修改日期等，Airtable也提供作為選項，直接把這些功能abstract了。

但以上的都只是Airtable 的基礎功能，其實際功能絕不止此，很多人喜愛用Airtable，更在於它的數據展示功能。

先以免費版的來介紹，Airtable 本身開發就支援多平台操作，包括Web、Mobile、也有Mac version。另外Airtable 上支持多種顯示模式，除了本身default 的Grid view（即spreadsheet 模式），如果有photo attachment 可以用Gallery view，有Date field 的可以用Calendar view。與此同時，table owner 可以制作簡單網頁版的e-Form，Airtable 就會提供form 的URL，就可開放讓其它人透過Form去提供資料。就這幾個功能，已經可以做出很多應用案例了。

而對使用Airtable 作team collaboration 來看，Airtable亦提供Kanban view，那大家可以想像更多功能了。無論是team 的task management，或者使用作Test case management，或者defect management，基本上都完全沒有難度。平台還有一個用法是用API調用Database，為識寫code 的人提供automation的選擇。

而如果用戶對Airtable 甚有興趣，甚至希望在公司層面應用，Pro 版的功能就更加強大，當中數據可以用於Generate Gantt Chart，或者 Generate Flowchart、Org Chart，也可以integrate Google Map visualize 地址等，還有很多周邊功能例如SMS / Email notification。筆者由2015年開始使用到現在，看著Airtable 不時也會發展一些新功能，每每出現驚喜，這是筆者另一個喜愛Airtable的原因。從這些新功能可以看出團隊中的product team 有很多新點子，團隊的執行能力很強，平台基礎建設也很好很方便擴展。

現時Airtable 已經是一間估值達美元 1.1B 的公司了，更加可以看到互聯網公司的威力。還是那句，互聯網世界會獎勵真正持續努力的人，由起初發展提供個人服務進而吸引使用者推介為公司提供服務，可能也是一種有效的營商手法。

「信息化」系列 -「線上購物」

疫情之下，大家減少外出，多了留家休養，零售商戶的業務大受打擊，沒想到這帶來了一次變革的機會。

今次疫情讓很多人初次使用線上購物，尤其是連零售店鋪也買不到的物品，例如口罩、消毒液等，唯有上網到外國網站買。而隨著疫情的延續，為了避免不必要的外出和接觸，一些生活上其它的用品也直接透過網上買。

從基礎層面，網上購物對買家和賣家也有很多好處，對買家來說，線上平台較容易搜索物品，也容易貨比多家，送貨方便差不多等於直接搬貨回家。與此同時，網上購物沒有時間限制，也沒有地域限制，這對於賣家面向消費者來說也是好處。而對於網購平台，沒有零售點的場地空間限制，亦可提供更多貨品供買家選擇。對比實體零售與網購平台，不難發現實體零售中有不少流程是冗餘的，包括分發貨物到零售點、貨物上架、收銀，還包括貨品到期的下架回收等，這些在網購平台都可以節省。

而網上購物更進一步的好處其實是所有交易數據的即時錄入，以及提供更多細化的數據可進行分析。基於減省了中間零售點的關係，產品的售賣和受歡迎情況能夠即時在數據上反映，免除了零售點報數的延誤。另外，網上購物的優勢還在於能獲取更多客戶數據，包括客戶本身資料，喜好，以至客戶在挑選過程中的「腳印」都可在網上平台上紀錄，因此無論是產品本身銷售、客群，以至客戶的停留和比較都可進行分析，商戶可以更了解產品的優勢，配合宣傳策略，達至更精準的營銷。而又因為減省了零售點，數據可更實時反映庫存狀況，達致更高效率的資源配置。

以往正常情況，不少人已開始使用網上平台購物，但更多的還是習慣使用實體商店，以致「線上化」的過程亦甚為緩慢。筆者也是傾向實體商店的用家之一，一來是在購買時見到實物較有信心，二來亦希望有問題時售貨員能解答。其實再細心一想，如果物品本身亦不能拆封或試用，實物與否其實並不重要，口碑反而可作參考，網購平台提供的評分及留言系統有這裏會更有用。而對於後者，不少網購平台已有安排客服，可處理客戶查詢，這類型的客服長遠甚至能比實體商店內做得更到位。

可以想像的是，「線上化」對於現職員工會有很大程度的影響，也需要一定的轉變。例如沒有了負責中轉搬貨上架的職位，需要轉型成直接送到客戶終端。文職例如收銀是完全取消，取而代之是線上客服及處理投訴的人員。

在今次疫情中所推動的「線上化」轉型，相信在疫情過後仍會持續下去，這也是時代的趨勢，追求更大效率及以數據做決策。現時筆者對跨國零售還是有一定保留，擔心點對點銷售會帶來大量重覆性的跨國物流需求，影響效率而且浪費大量資源，但對本地零售的線上化則大為支持。尤其是在香港地少人多的環境，對零售店鋪的需求造成租金大幅上漲，我們的消費當中亦有不少部份是為支付鋪租，長此下去只會侵蝕整體生產力。當然，網上平台不代表就沒有收費，分別只是互聯網世界會獎勵真正持續努力的人，而並非靠祖輩優先購買地皮的人。

讀者如對筆者的文章有興趣，歡迎到訪其它「信息化」系列的文章：
《「簡化」篇》
《「流程化」篇》
《「無紙化」篇》

關於Blockchain（區塊鏈）的介紹和想法

之前幾周分別寫了Cloud，Open API及Microservices，都是側重Tech 而不太industry-specific 的題目。今次試寫Blockchain，Finance 色彩會比較濃。

原則上Blockchain 並不一定與金錢交易有關，任何的紀錄也可以在Blockchain 上儲存及成長，不過如大家所認識，Blockchain 最初的普及出現是Bitcoin，到目前來說最普及的應用也都是在cryptocurrency 上，短期內頗多的應用場景還是跟金融有關。

有很多人說區塊鏈是互聯網時代最具顫覆性的創新技術，透過集體分散式演算，毋須任何一方作為中介機構進行主數據管理，處理了中介信任問題。同時區塊鏈上的數據完全開放，任何參與者也可以查閱，並共同維護數據，可以說是完全解決了信任和數據準確性的問題。

基於區塊鏈本質上是一個又一個的區塊的鏈接，原則上所有區塊鏈也可以追朔到區塊鏈的起頭，以及每一次更改（每一個區塊），所以亦有人視之如同Ledger 或歷史紀錄一般，亦有人用「Distributed Ledger」來形容。

區塊鏈有多個特點，其中最重要的特點是「去中心化」和「不可竄改」，所有互聯網上的參與者都負責共用維護數據的完整及準確，任何一個交易的進行，都需要得到超過一半的參與者認可方為作準，這種模式帶來了革命性的多種好處。

首先，「去中心化」或去中介化，免除了單一中介承擔數據管理和準確性的責任和風險，當中風險包括單一維護數據可能發生的人為錯誤，或數據遭入侵修改的可能，為數據本身帶來高度「安全」。而且，數據準確性是基於參與者共同遵守的規則（如演算法）而定，不需依賴任何單方進行校驗，在多方校驗下數據更能確保「準確」。與此同時，免除中介亦同時免除了中介的「費用」。

原則上，基於所有交易必須經超過一半參與者認可方作準，只要參與者數量足夠多的話，基本上很難竄改，而大部份參與者遭同時入侵的機會亦微乎其微。

不過區塊鏈目前大部份的應用場景仍然是在理論層面，多數的項目現時仍在實驗階段，而且基於「去中心化」的特性，與現有法例中的AML/CFT有不少抵觸，也影響了一些項目的推進，很多金融業內的區塊鏈項目也並非能真正做到「去中心」。

其中一個待處理的問題是區塊鏈雖然說數據公開透明，但公開指的是區塊及交易紀錄的出現，內裏的交易雙方資料卻是可以加密隱藏的，這讓一些交易可以匿名進行，完全違反了AML/CFT的監管需求。例如Bitcoin雖然目前已經達到自由流通的狀態，公開市場上亦有價有市，但為數不少的國家仍沒有視Bitcoin為合法貨幣。

另外，本身在技術層面，區塊鏈由出現一直產生的歷史紀錄，造成龐大數據容量需求，而且會不斷加大，亦需要參與多方同時維護，亦產生多線並行computing power的需求，長遠來說並不合乎效益，Bitcoin的掘礦模式就一直被人垢病浪費大量電力資源。因此區塊鏈要容許大量參與者廣泛應用，仍有技術難點需要突破。

但區塊鏈的潛力還是很大的，隨著更多資源投入研發，相信技術問題在可見將來亦有望解決，而區塊鏈亦已有不少潛在應用場景，下篇續寫。

辦公室軟件介紹 - 筆記工具

繼續生產力工具系列，今次介紹的是辦公室筆記工具。

筆者在成長過程中，不同時段也使用不同的工具作筆記。最初的時候是用筆記簿，好處是把所有筆記紀錄在一起，壞處是難於搜尋，試過做目錄，算是初步解決，但也不很方便。

後來感覺用紙筆的方式還是有所不妥，正式改為使用電腦去記。用紙筆記的統統也都轉用電子紀錄，當中有用過word、excel，簡單連notepad也有，搜尋算是方便了。但這時候發現筆記還是太多，用key word搜尋會找到很多紀錄。而且同一件事情，用不同角度看可以有不同的歸類，尤其是隨時間變動，這種情況出現更易發生，導致經常要花時間重新整理，效率不太好。

至於現在，自從發現了Microsoft OneNote後，基本上能滿足筆者的所有需求，暫時亦未有發現其它可取代的方案，簡直算得上是如獲至寶，本篇也就分享一下OneNote的好用之處。

首先是「分頁功能」，OneNote 入面的分頁基礎可分三層，最高層是筆記本，第二層是章節 (Section)，最低層是分頁 (Page)，用家可以按使用筆記範圍決定如何編配分類。比如說筆者現時所跟進的項目來自幾個不同部門，每個部門有若干項目條線並行，各個項目條線有定期會議，筆者就會用最高的筆記本層分開部門，章節分項目條線，每個Page則是每次會議的紀錄，或是一些自己整理的notes。而無論怎樣擺放，也很容易就透過搜尋功能找回筆記，這對筆者來說尤其重要。

另外一個好用的是 Input Format 的多樣性及自由度。開啟OneNote基本上是先見到一張白紙，上面可以Type Free Text，可以繪圖插圖，Word 的Text Format 基本上也是有的，也可以加Table 作簡單列表當Excel 用。最重要的是每一個這些element 也是可以在同一頁上隨意移動，沒有Word或Excel的分行限制，換言之take notes 時可以任意寫，最後整理時把有關的搬到一齊就可以，這個很符合mind map 的思維模式（事實上筆者也經常用OneNote來做Mind Map）。

還有就是OneNote 超可靠的同步機制。鑑於Word, Excel以至PPT 都是為群組share 而設，本身在sharing方面就有一定的限制（例如要save 才會commit change）。OneNote是主要以用家個人使用而設，online sync 基本上是real time自動的，這樣在不同電腦上延續工作就變得相當簡便。尤其是如果公司有使用Microsoft 365，在不同電腦以至Web Access 都可以同步，工作就更加不受platform 所限。

還有一些就是能夠連接其它Microsoft Office 工具的附加功能吧，例如待辦事項，連接Outlook 上的工作，複本note image製成電子郵件，紀錄audio 等，不過這些筆者也不多用，不作詳細介紹。

當然也要說一下，以上所說的OneNote起碼是2010 打後的版本，如果機構還停留在2007 甚或更前，那最好還是先提升一下，跟一跟上時代的步伐吧。

淺談「信息化」(「簡化」篇）

上兩週分別介紹了「無紙化」及「流程化」，兩者都是「信息化」的手段方法，本週繼續寫的是「簡化」。

無論是「無紙化」及「流程化」的項目，背後其實都需要有一個很重要的思維，就是我們並不是簡單的複製現有表格及流程到系統上，亦需要在項目過程中進行「簡化」。

在「需求分析入門 - 電子表格」的篇章中提到，很多時候紙質表格經過多年沒有整合或Review/修整，當中很可能有大量重覆的欄位，另一可能則是有些欄位已不再需要。所以在「無紙化」項目中，我們要切記不可直接複製，更要看的是合理性及可用性。在現今世代，更加應該考慮的是用戶體驗的流暢。

例如一張現有客戶申請附加服務的表格，紙張表格很多時要客戶重覆填寫個人資料，這個對電子表格來說是完全不需要的，既然已經是現有客戶，所有這些資料都應該已經儲存在系統內，根本沒有需要再問客戶。而即使客戶資料真的有所更改，亦應該透過申請更改資料的流程進行，切勿把表格設計成更改資料和申請附加服務bundle 在一起。

另外，我們要理性地分辨現有表格上需要填寫不同資料的背後原因。紙張表格最初設計很可能是為減少不同樣板，才把多個用途的申請放在同一張表格上，但在「信息化」的世界，我們更應該考慮的是把功能服務合理切割，並按實則需求而調用適當的服務，需要客戶提供的資料，應按實則背後原因而定，這些都可以透過定義系統邏輯來實現。

「流程化」也是類似的道理，在現有流程中，按服務實則需要檢視有哪些部驟是必須的，哪些為不必的。亦需要把不同服務的流程合理切割，把可重用的流程變為獨立service，切勿把沒有必然關係的工作bundle 在同一個流程上。

另外，也要考慮流程中的交接點，即由一個party 轉交到另一個party 的節點，原則上是愈少愈好，同一部門應盡可能一次過完成所有工作，避免多點接觸同一個case。流程在設計上更要切忌製造可能出現loop 的情況，避免部門之間互相射波。切記流程並不是對話框，有問題有escalate的出口，而不是無止境射給別個部門。

當然以上種種考慮，在僵化的制度或不肯接受改變的機構內是頗難執行的。我們需要的是開放，能夠接受新事物的態度。在筆者的朋友圈，相信有不少已晉升至初級或中級管理層，希望進來看這個Blog 的朋友也努力在自己的岡位上牽動改變，實行「小改變 大改善」。

關於Microservices（微服務）的介紹和想法

本週寫的題目是Microservices，跟上兩周寫的Cloud及Open API也很有關連。要了解Microservices，首先要先了解 Service-Oriented Architecture (SOA)。

傳統我們認識的系統，尤其是back-end 的平台，大多都以一個整體形式出現 (monolithic application)，所有無論是產品定義，業務邏輯，流程，審批，UI，static data，parameters，報表，統統都放在一個平台之上。以銀行作為例子，一般的核心系統，財資系統，理財產品平台等，都以這種形式出現。後來系統慢慢演變，為了更有效分工管理，同步開發，系統裏出現了modular-base的概念，基礎可以分成不同的module，由不同團隊營運，但原則上還是一整個系統。

SOA是互聯網世界的產物，原理是把原身為整體系統的各項功能，變為獨立個體，並且可分散到網絡上不同地方，以web services 形式在網絡上互通。

SOA 其中一個最大好處是將application layer 從platform 獨立出來，以往我們在整體系統上，無論怎麼應用modular concept，始終application 選定了某個平台，就要整體放在同一平台上。盡量選擇一個平台獲得最大好處，但也要容忍一些不是太好的地方，在SOA容許各項功能分為獨立個體，代表這些獨立個體可以各自建立在最適合的平台，實際各自實施方法並不太重要，只要大家符合同一套Architecture，並提供API互通即可，這提供了一個機會供各個個體獨立持續開發。

SOA另一好處是可以建立一些公用service，有好些服務是很多系統都需要，但以往的做法是各自做，浪費了很多資源。用一個很簡單的例子，比如一個服務就是查詢某一日是否公眾假期，在銀行的世界裏，可以說幾乎每一個後台系統也要儲 holiday table。另一個常見例子則是用戶職級權限，也是定義在各個系統上。SOA 原則上可以提供獨立統一接口供其它service 使用，減少重覆開發甚至參差不齊的情況。

SOA以Web Services 為基礎，可更容易與Open API或其它API management 平台對接，是本欄一直推崇的未來系統協作模式。

初步講了SOA後回到Microservices，Microservices 是SOA 其中較特殊的一種，在SOA 的要求之上，更加著重 lightweight，分工更加精細，之前提一中土弓Cloud 所著重的 Scalability，其中一個重要先決條件就是Service lightweight，容易Scale up/down，而Microservices 正符合這個要求。

不過要實施 Microservices 也還有不少問題要解決。其一是Service 分得太散，系統容易失去整體視圖，亦更難去解構service 之間的關連性，需要更有系統的辦法管理。另外不同service由不同團隊負責，也會出現像人員分配的問題，需要防止多人做同樣的工作，或有工作跌入灰色地帶。而且還有network latency 的問題，試想一個program，要做任何事也要找其它service 幫忙，技術上可行但恐怕等候時間太長。

原則上，目前並沒有一個統一的說法，究竟有多lightweight 才算是Microservices。一般來說，lightweight 的目標為容易scale up，但也要考慮以上的各點。不過在現階段，即使沒有真正或全面的Microservices，至少我們可以先向SOA過渡，例如先把公用service 分拆成獨立個體，減少資源浪費。

另外也可以考慮是把一些周邊module 分拆，好處是可先為現有系統功能減磅，而不影響核心業務。始終業務也需要持續營運，如果選擇big band 方案綑綁一次搬遷到SOA架構的方案，項目需時太長會很難支持新增業務，遷移風險也頗大。