Showing posts with label 數字化轉型. Show all posts
Showing posts with label 數字化轉型. Show all posts

Saturday, December 12, 2020

對數字化的重新思考

早些時候在網上搜集材料,有幸拜讀了不少成功進行數字化轉型公司的案例,重新思考了數字化的意義,但是一直也未有時間進行整理,更不知應從何處開始著筆,很有種overwhelmed 的感覺。

關於數字化的定義,坊間有很多不同的說法。有人說打從人類歷史出現可以儲存資料的電腦開始,就已進入數字化年代,也有人說數字化是由以iPhone為首的移動設備,提供了平台收集大量數據所啟動,亦有人說數字化是透過人工智能、機器學習或OCR等技術,將實體轉化為數字格式的過程。姑勿論哪種說法最為準確,毋庸置疑是我們現在正經歷著數字化帶來的急劇轉變,深刻地改變著各行各業、經濟及社會結構。

正如兩百多年前的第一次工業革命一般,現今世界的數字化轉型也是由新技術所推動。大量而廣泛出現的技術突破,在應用層面落地並且互相融合,為各行各業提供了無數提升營運水平的機遇。如果說第一次工業革命是以機械為代表取代人力的自動化,減低營運成本,數字化則可以說是借助信息數據的力量提升分析及預測能力,全面改造商業模式,創造價值。

一般情況下,企業的數字化轉型都需先從信息化開始起動,也是過去數十年的IT項目所圍繞的重點,從客戶數據、業務交易,到內部審批、財務報算等,統統都紀錄到各個軟件系統內。繼而,系統內可以加建邏輯把既定業務流程固化,由系統協助確保流程有確切執行,也可加入防錯機制。再繼而,系統可把既定而重覆性的工作整理,大幅度把重覆的邏輯自動化執行。

信息化的結果,是企業內大量的營運數據都紀錄到系統之中,然後,有些公司嘗試從數據之中發掘價值,包括營運過程中可以改善的流程,善用閒置資源,優化供應鏈、現金流等。去到近十多年,智能裝置的普及,配上物聯網,再加上大量新技術的發展及落地,數據更加是海量增長,成為企業營運持續優化和創造價值的原動力。有人說,掌握數據就是掌握天下,也有數據是新石油的講法。

到今日,數字化已經是時代的大趨勢,企業不再有餘地選擇是否進行數字化,因為無法推行數字化的企業必將被淘汰。而對於個人而言,無論投身各行各業,又或是公營機構,數字能力也將是必不可少。學習和了解新技術,理解背後原理,創新設計應用場景,提升效率,將是每個身在職場的人都需要面對的改變。

未來世界裏,隨需服務基本上是默認選項,更多的智能化,更精準的判斷,將成為每個企業賴以生存的營運目標。個人認為有幾項新技術是必須要有基礎認識,也是未來世界所必然需求的。

第一是雲端運算技術,提供可隨需擴展的運算資源。企業可同時減少對實體硬件的依賴和維護,減少閒置資源的浪費。另外,雲端提供集中算力,可作為載體為其它新技術輸出服務。個人預計雲端運算會是未來的默認選項,既有軟件也必須提供雲端操作版本。掌握領先雲端技術服務的企業,將會是數字化時代的必然嬴家。

第二是圍繞萬物互聯概念的技術,包括智能裝置,通訊技術和開放接口(Open API)等。透過智能裝置即時獲取的數據,透過通訊技術提供即時傳輸的平台,通過開放接口供隨需運算調用,能夠讓實體環境在虛擬世界中重新建立,進行更精準的分析,更實時的判斷,預計路面上全面自動駕駛也將在不久的未來出現。

第三是圍繞自動化概念的技術,包技人工智能、大數據和機械人,這些基本上是所有數據分析及預測判斷的核心。每個企業,每個業務,每個功能,都可以按自身情況和目標,自行定製標準,提供無限創新意念的可能性。

第四是區塊鏈技術,尤其是在金融場景的應用,例如數字貨幣或跨境貿易。但個人來說並不認同Bitcoin 這種必需要透過巨量燃燒地球資源以穩定平台及保證紀錄正確的操作,寄望將來有更有效的區塊鏈技術出現。

最後結語,世界很大,但人很渺少,時間也有限,能夠投身其中集中精力研究一至兩項就已很不錯,後續會再就每個技術再細化紀錄。

Thursday, April 30, 2020

從澳門「電子消費卡」看電子貨幣

疫情之下,全球多地也推出紓緩經濟壓力的措施,除支援企業、支援就業之外,更有直接派錢增加消費撐經濟,不過各地的做法也很有不同。

以美國用支票派錢為例,可謂金融界中一個最「傳統」的方法,又要郵寄,市民收到又要再去銀行入 cheque,還要經過一大堆背後的cheque processing流程,在現有的金融基建底下,實在想不出為何還要用這種「傳統」方法。

另一個例子是澳門金融管理局發行的「電子消費卡」,卡上貨幣的面值跟澳門法定貨幣一樣,可以算是「電子貨幣」的一種。但「電子消費卡」不能兌換成現金,亦限定了使用期限及每日限額,市民首先要去領卡,也不是所有零售點也接受讀卡。不過如果從澳門的派錢目的來看,「電子消費卡」可以確保派的錢是花在本地經濟,不會立即就用了去買新iPhone 或去旅行,又未嘗不是一個好主意。

「電子貨幣」的概念,近年一直被廣泛討論,尤其在Facebook 提出發行Libra 之後。筆者一直提倡「去現金化」,早前的篇章亦提及不少使用現金的缺點。由央行發行電子貨幣,可以起到帶頭作用,也有助提供更穩定的流通貨幣。

現有我們在常用的例如PayMe,可以視作電子錢包,但背後仍然是實體貨幣,只不過是儲存在銀行體系內。更符合「電子貨幣」定義的應該是比特幣 Bitcoin,由發行到流通,完全是電子形式出現,但Bitcoin 一直為人詬病是其價格大上大落,屬炒賣成份多於平時流通使用的交易貨幣,這亦很大程度源於Bitcoin 背後沒有央行以貨幣政策維護其價值的穩定性。另一問題是Bitcoin 底層使用的區塊鏈技術,雖有助維護其交易紀錄的正確性,但付出代價是需要虛耗大量計算資源,長遠而言對地球資源是有害多於有利。

近年就有以央行名義發展的「電子貨幣」(DC/EP),以科技發展趨勢而言,這也可說是必然出現的結果。「電子貨幣」減省的是實體貨幣帶來的印刷/印制、儲存、防偽、老舊回收的問題和成本,另一方面亦提升交易效率。借助央行發行的「電子貨幣」,可以有效支援外匯兌換,亦有助處理電子錢包之間不能互通的情況。當然,電子貨幣亦同樣要面對偽冒,盜竊等問題,但電子紀錄將能更有效的追踪偽冒的來源和盜竊的流向,可以視為能夠大大減低風險的方法。

澳門今次推行的「電子消費卡」,當然技術上很不同,使用亦有很多限制,但亦可以視作為「電子貨幣」的試點應用,讓社會各界更了解用戶的使用習慣,以及更進一步了解其優缺點。與此同時,澳門政府借此亦更能評估「電子貨幣」的最終流向,有助檢討派錢的實際經濟效用,如有需要的話更可採取導向式的「電子貨幣」,促進計劃經濟。

無論如何,去現金化或電子貨幣一定是科技發展的必然結果,大家更應著重的是技術發展的同時如何兼顧安全、私隱等問題,讓科技為社會帶來真正的益處。

相關篇章:
關於「去現金化」的想法
疫情之下思考「去現金化」的發展

Wednesday, March 18, 2020

「信息化」系列 - 論排隊

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

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

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

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

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

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

Wednesday, March 11, 2020

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

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

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

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

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

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

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

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

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

Wednesday, March 4, 2020

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

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

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

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

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

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

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

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

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

Wednesday, February 26, 2020

續談「信息化」(「流程化」篇)

上週的Blog 談了「信息化」中最初階的「無紙化」,本週續談另一個重要過程「流程化」,相對是複雜一點但也可歸類為初階範疇。

上篇提到「信息化」可以理解為把數據轉移到數字信息處理的一個過程,「無紙化」用電子表格是第一步在收集需求的時候已經成為電子數據,「流程化」則協助將數據轉送到不同系統上應用,情況就像是空氣進入肺部,經由血液送到不同器官上使用。

在資訊科技的發展歷史洪流,今時今日我們所使用的系統一般都是按其domain 而建立的。每個系統有其特定用途,以方便維護及升級時不影響其它系統,少有一個系統可全面完成所有工作,最多只會是一個portal作為front-end UI,背後建立接口到後台各大系統上。有趣的是,操作的人也與系統建立密不可分的關係,稍具一定規模的機構內,少有人可以單獨完成所有任務。在這樣的背景,多數系統也會有屬於自己的數據,而他們當中會有共用的數據,「流程化」則有系統地協助進行打通系統通道的任務。

一般我們會需要使用流程,是在機構內一些特定的工作中,互相之間有其關連性及依賴性,即某一個流程節點是基於另一個節點的output,亦作為下一步的input。例如一個申請入會的流程,牽涉的節點可能包括:
填寫資料 -》提交証明文件 -》提交申請 -》內部審批 -》通過申請/拒絕申請
當中填寫資料可能是一個前台Web 或App的電子表格,申請的資料會暫時紀錄在一個流程平台,連接到不同審批rule engine 系統做內部審批,通過或拒絕申請則經由notification server 發送 SMS/Email 通知申請人,最後成功申請的個人資料則儲存紀錄在CRM平台的客戶資料模塊上。

在以上例子中,可以看到客戶申請入會的資料需要流轉到不同系統,如果每次進入一個系統都要輸入一些重覆的資料,肯定費時也容易出錯。透過「流程化」,我們可以做到系統信息在有系統之間互通,亦可以在流程當中加入邏輯控制。例如特定情況走某些或不走某些流程節點,這樣做更有助standardize 整個流程會出現的各種情況,就不需要靠人腦去死記,也大大減低出錯機會。另外,流程一般也會配上當前狀態及Action Party(即當前需要跟進的團隊),這樣流程的狀態就更一目了然了。

本週需求分析系列將會更詳細寫如何有效收集流程需求。

Monday, February 24, 2020

關於Open API的想法

近年各行各業也大推Open API,香港各大銀行在金管局牽頭下也陸續推出,提供更多service 供外部開發者使用。筆者很贊成Open API的想法,唯對目前的實施方法和成果並不太樂觀。

傳統銀行業的內部系統通常以業務作為單位,存款貸款理財投資各有獨立系統支持,本身就算內部各系統互通訊息都需要獨立建接口,Interface 也隨個別系統而定,少有統一制式,多數也只是做到多渠道共享同一接口,或用ESB將接口盡量統一。

以這樣的背景推進Open API,可以預期的是能夠開放的API將受限於產品平台現有能支援的接口,結果很大機會是在現有網銀及APP外新增多一個渠道。另外由於每個接口需要重新思考access control及authentication,又要照顧performance,初期只支持一些查詢功能,或提供static information,實際用途不大,成本效益就更低了。

筆者認為要推行Open API,機構內部亦需要很大程度提升現有各大平台的API 管理及服務範圍,甚至應更進一步推進升級為以Web Services形式提供服務,以更便於與外部開發者共享同一套API。

以Amazon 為例 (當然這是最好的例子),今天我們都知道Amazon 內部系統通訊全部都經由Web Services進行,這全是基於Amazon 在很多年前開始推行的改變。無論任何一個業務組,其轄下功能和資料都必須提供Web Services共享,業務之間只能通過Web Services交流,不得經由其它途徑,不容許共享內存,更不容許後門程式。各業務組亦需要負責為功能寫documentation,目標就是日後能直接將服務公開,而服務亦終於在2006年以Amazon Web Services (AWS)為名推出市場,當中不少服務容許介面操作同時亦容許API調用,對開發人員極為方便。

回望今天銀行業以及很多的大型機構,內部系統按業務需要而採購,系統多以照顧業務本身運作流程而設,本身並不太考慮對外對接,因此業務需求亦多以滿足介面操作為先,只有在需要時考慮提供調用接口,要提供 Open API 就更為不便。

要像Amazon 般全面更換成Web Services的話,牽涉到可能要重寫大部份系統,成本基本上沒可能做得到合理,較為合理的方法反而是建立API management layer,以不大幅影響後台產品系統架構為前提,盡量開發更多接口,集中管理。以這種思路發展,API management 亦可自成獨立系統,除處理像ESB的功能,亦管理authentication,處理分流等。API management platform也可以有lifecycle management,容許backward compatible,在多渠道多產品的環境就更為適合了。

面向未來,在 Bank 4.0 的背景,銀行應更為走向發展作為基建,提供更方便的途徑供各行各業及個人使用,Open API 絕對是在走對的一步。

Wednesday, February 19, 2020

淺談「信息化」(「無紙化」篇)

「信息化」轉型這個不是什麼新詞彙,在資訊科技界也談了不知多少年了,現在基本上甚至已被「數字化」取代,但坦白的說,今時今日我們仍然還在這個旅程之上,不少行業仍然處於「信息化」的起步階段。

「信息化」可以簡略理解為把數據轉移到數字信息處理的一個過程,自從人類歷史出現第一台計算機,第一個數據庫,我們初次踏上了「信息化」的旅程。業務上的數據,包括客戶,產品,交易,對賬,規則,流程,各式資料都可以錄入到數據庫中,然後數據可以用來分析,造成有用的資訊,數據可以流通,經流程化可以在各個流程節點應用。

而今時今日較新的技術,包括人工智能、機器學習、大數據、雲計算、物聯網,更多現實生活中的事物都可以實時自動化轉變成數據儲存,圖像、影像、聲音、free format文字,同樣可以流通,分析,幫助我們改善生活,我們開始從「信息化」過渡走入「數字化」。

在這麼多的新技術出現的背景下,理論上資訊應更加透明,我們亦應能更依賴數據作出決策,但在現實生活,我們看到或感受到的卻是另一回事,基礎技術是發展得很快,但應用卻是大幅落後,個別行業更可以說是停留了在原始社會的階段。

對這些仍然留在原始社會的機構(包括政府)來說,「無紙化」和「流程化」應是踏入「信息化」的初階第一步,下面先說「無紙化」。

早些年筆者每次到康文署申請活動,都有一個很不快的經歷,就是申請活動必須要填紙張表格,尤其是當一次申請不成功要重新申請時,又要把整張表格重新再填,而我知道康文署內部也有系統紀錄申請,即是說,填表格時辛苦,把資料輸入系統更辛苦。

其實要將表格電子化,可以說得上已經是最低的要求了,網頁填表沒有甚麼很貴的技術含量,從項目角度來說也可以說是入門級,即使現在已經有OCR技術,準確度也很高,但也總還要有人去做 sample check,把這些都計算成本後,就真想不到有甚麼理由不去電子化。

不過康文署也只是其中一個較常見的例子,其它政府部門或大型機構也有不少這些情況,要讓香港走向智慧城市,其實每個機構,每個部門,每個崗位都應盡責任,檢視自己管轄範圍內的各項流程,而第一步就是做到無紙化,由源頭的原始數據開始就使用軟件收集。領導層級的責任,則是加入KPI, 每年量度剩餘仍需要用紙的流程,務求逐年減少,最終減至零使用。

這個其實也是應用「小改變 大改善」法則,當愈來愈多的資料「信息化」,信息更易分析流通,整體效率自然有望提升,但要真正見得到成果,需要第二步「流程化」配合,另一篇blog 將會進一步談。