談一談《BANCS系統「十日談」》

2021-06-18 06:45:49 字數 4123 閱讀 3565

前一陣在論壇看到《bancs系統「十日談」》,感覺對bancs的讚譽有點過。首先宣告,我對bancs系統沒有偏見,對以前的系統譬如nacs也沒有任何特殊的偏好,只是覺得應該有一說一,咱不能好就好上天,壞就踏上乙隻腳。下面將針對「十日談」的觀點談一談。

「十日談」:首先——天賦異秉!bancs系統徹底顛覆了我行以往業務系統的觀念,引進了全新的核心銀行系統理念,是乙個完全以客戶為中心的生產系統。

新一代會計系統nacs也是以客戶為中心的核心系統,當時提出的企業資料模型使用唯一客戶號,就是為了建立以客戶為中心的生產系統,從這一點來講bancs系統的「天賦異秉」無從談起。

「十日談」:其次——滿腹經綸!覆蓋了舊線的nacs、rts、niss、nics等等系統的功能,減少了一筆業務要跨多個系統處理的歷史。

覆蓋了這麼多系統的功能?「十日談」自己不是說,「當然bancs大俠也不是事事親力親為。比如他更關注交易的處理」。其實bancs也僅僅是登記了交易,沒有生成銀行最基本的借貸賬,哪來的「滿腹經綸」。

「十日談」:再次——武藝高強!500多天來,系統執行穩定,期間只短時宕機一次。(要知道,以往新系統投產,水土不服,宕機狀況屢有發生,此大俠居然毫不失手,不能不叫人佩服!)

新一代各個系統投產也僅僅聽說系統不好用,沒有聽說過宕機狀況屢有發生,咱不能無中生有。

「十日談」:再再次——性格倔強!嘿嘿,金無足赤,人無完人,大俠也不能無所不能。尤其當操作人員出於對bancs不了解,就會有不知如何處理的情況發生,導致了大家對大俠一些誤解。然而真金不怕火煉,真大俠不怕考驗,通過大量的培訓、錘煉,我們已逐漸掌握了與之相處之道。

性格倔強是不是就是要求大家「通過大量的培訓、錘煉」去適應它嗎?

就筆者粗淺的知識,知道此位大俠來自南半球的澳大利亞,一路飄洋過海來到我行。在此之前,他曾經在澳洲、西歐、台灣等地區的一些銀行成功執行。

本來確實不應該問英雄出處,但作為it業內人士,可能從來沒有聽說過澳大利亞還出產軟體,鐵礦石但是賣的挺貴,入股合同籤了還能毀約賠錢。「曾經在澳洲、西歐、台灣等地區的一些銀行成功執行」,沒有聽說大的銀行執行案例。再說何來英雄之說。

「十日談」:第二日 bancs大俠之名號

此番所說的名號,乃指bancs系統的交易碼。bancs系統的交易碼非常多,但規律明顯:…

又有看官挑戰:09760是什麼意思?俺只能苦笑,無語。因為俺只知道是修改密碼,但套不上上面的邏輯。那就使出絕殺技——不求甚解,死記硬背。

bancs系統的交易碼是令新使用者頭大的地方,現代使用者介面的設計都講究人性化,交易碼最多只能作為乙個快捷人口選項,系統使用的快慢決定於交易畫面的輸入及後台賬務和業務的處理,而不是僅僅是選擇交易的快慢,繁多的交易碼逼迫使用者死記硬背,感覺從web時代回到使用字元介面的蠻荒時代。

「十日談」:第三日 bancs的地盤bancs做主

…bancs作為乙個核心銀行系統,也是對個人、公司依據一定條件開立、記錄存款業務的賬戶,但賬號是無意義的為17位數字。…

其實,各位看官有所不知,bancs 大俠的這招,可謂是深藏不露,無招勝有招。只要是入了本派,無論你是在北方大漠,還是南沙諸島,只有乙個代號。無論你是轄區變換,還是職位公升遷,代號只有乙個,那稱呼你的人多方便啊。所以我們送bancs乙個尊稱:以人為本。

現代會計系統賬號的設定一般都採用了序號的方式,這種用法與軟體設計原則中「單一職責原則」是一致的,即賬號的作用是標識賬戶,只要滿足唯一性條件就可以了,這樣如果系統發生大的修改,賬號也不用變化,不像以前的系統賬號包括了貨幣核算等諸多資訊。只是這種設計與以人為本有什麼關係。

「十日談」:第五日 bancs的兩大獨門暗器:一本賬和二次更新

而所謂二次更新,更顯bancs大俠心思縝密。比如,今兒事務繁忙,大俠即號令手下,凡櫃檯發生金融交易,先寫進交易日誌,待閒時,再用二次更新程式(sy1000) 從日誌表讀取交易記錄並將分錄寫到總賬介面檔案中(glif)。

怎麼樣,諸位感覺如何?大俠果然是大俠,事無鉅細,井井有條。

採用這種方式,藍圖內部的人士能否介紹一下沖正交易和事後審核等工作是否比較困難?

「十日談」:第六日 bancs的有所為有所不為

身為掌門,當然bancs大俠也不是事事親力親為。比如他更關注交易的處理,而對於統計報表、利潤分析等等事務,一概安排給總賬系統幾個「長老」去做。「長老」們分工如下:如mis系統負責統計類報表,pa負責利潤貢獻度分析,還有個長老(名字俺忘了),負責整合報表。

pa(利潤貢獻度分析系統)將負責全行分機構、分產品、分客戶等維度的利潤貢獻度分析。該系統涉及上存下借、內部資金轉移計價、減值準備、中間業務、內部分潤等十餘個業務功能。

明白了這一點,我們就不要要求掌門管太多的事情。要知道,如果掌門事必躬親,即使他是三頭六臂,也會影響他的工作效率,豈不是得不償失。

從第六日就可以看出來,bancs確實就是乙個記錄交易的系統,其它事情都交給其它系統完成,從銀行系統整體架構上看,確實算不上是核心系統。

「十日談」:第七日 bancs系統中的核准人員與舊系統複核人員的職責差異

bancs和以往我們使用的系統還有乙個非常巨大的區別。如:舊線系統中,無論什麼業務,都要設定乙個經辦乙個複核。複核要對經辦所做的每一項工作負責。無論大事小情,上至賬號金額,下至漏章錯字,吃喝拉撒全負責。如此設定,表面上看起來是覆蓋全面,天衣無縫。而實際上,其中的隱患不可謂不深:第

一、經辦複核之間很容易產生依賴心理,進而產生操作性風險,是謂之「集體負責等於無人負責」;第

二、複核關注的點過多過雜,容易削弱複核的注意力,有時會抓芝麻丟西瓜。

我們再來看看bancs,想當初俺看到大俠的安排時,就彷彿天際一道閃電,頓時照得俺如醍醐灌頂——世界上咋有這聰明的人哩?千言萬語化為兩個字:佩服!

諸位看官,請聽俺細表。

由於bancs系統是乙個交易驅動的系統。所謂交易驅動,就是只要櫃員明確自己想做什麼,選擇正確的交易碼,那麼後台的會計核算會自動生成,永遠不用擔心用錯核算碼。看到這裡,有些看官恍然大悟:想當年用nacs時,會計核算可是乙個最重要的環節呀。常常出現給客戶記賬記得對,但是輪到寫對方科目時,卻給記錯了,結果衝賬時連客戶賬也得一塊衝。耽誤時間不說,跟客戶也不好交代呀。「嗯~~(捻鬚晃腦),bancs高出一籌。」

其實,bancs是交易驅動,意味著複核人員不僅不用關注會計核算,同時也意味著不用關注匯率折算、回單繕制、統計報表等等事務。甚至一部分交易還控制了對諸如匯率型別、跨客戶號入賬等等錯誤的控制。可以說,現在想犯點錯誤都難。在這種情況下,如果每筆業務,尤其是小額頻繁發生的業務,仍然按以前的模式設定乙個經辦乙個複核,實在是極大地浪費。

本人實在是水平低,說了半天,我也沒看出bancs系統高明之處,舊線系統不是也可以單人臨櫃嗎?「十日談」所舉衝賬的例子,只能說舊線系統有效性檢查不夠。再說中行內部有沒有評估過bancs上線前後節省了櫃員多少工作量。

「十日談」:第八日 大俠也有「腳踝」

bancs雖然貴為掌門,但也有自己的軟肋。具體的說,就是涉及到一借多貸、多借一貸乃至多借多貸等等舊線常見業務時,由於此種情況與bancs的設計理念完全背道而馳,會將這位掌門愁死。好在bacns中還有bgl賬戶,並有若干bgl交易(如bgl與客戶賬之間的對轉、bgl與bgl之間對轉),通過它搭橋,完全可以避開這些困難。

如果bancs實現連一借多貸、多借一貸乃至多借多貸都比較困難的話,確實對不起「大俠」的稱號,要知道這都是會計的基本賬務要求,通過其他方式避開困難,會計人員會不會感到困惑。

第九日 玩轉bancs

操作竅門涉及兩個原則:一、盡量多使用鍵盤而少使用滑鼠;二、充分使用系統提供的一些熱鍵。

…3、很多交易都沒有歷史查詢的功能。如果非要查,可以使用「日誌查詢」功能進行查詢。

「充分使用熱鍵」,這種理論在使用unix系統的時候就耳熟能詳了, unix系統使用者介面設計理念讓駭客們體驗還行,動員中行全轄老少櫃員都這樣用確實有點難為他們了。

第十日 如何與bancs 相處

既然使用bancs,那麼就要尊重他的設計理念。如果系統流程與現有的業務操作規程不相適應,那麼做何取捨,就是非常重要的。如果非要用陳茶沖水,又如何能夠得到新鮮的茶香?!舉個例子來說,bancs中的匯款類業務,完全通過介面從電訊系統接收報文,櫃員在bancs系統處理後,會計賬戶自動生成,根本無需列印報文、繕制會計傳票,即完全實現了無紙化處理。但是一些部門根據以往的會計傳票規定,硬性要求傳票中包含報文和傳票,就要求櫃員使用專門的交易去列印,既浪費了時間精力,又導致了人員的浪費。

這種情況已經得到充分關注,並設立了流程整合專門部門,相信以後會越來越順。

這些部門swift的使用理念確實落後,如果為此專門成立流程整合專門部門,確實有點小題大做了。

總的說來,難得有人這麼詳細介紹了bancs系統,讓局外人也能一窺管徑,再說「十日談」這個名字確實取得有點意思。

《十日談》摘要1

職業生涯 前2年是學習技能的階段,這個階段主要精力放在專業技能的提公升上,2年內起碼要趕上平均水平,即所謂 中級 在這個階段的人通常對軟技能不怎麼關 注,溝通能力達不到平均水平,基本上是來啥活幹啥活,幹不完就加班的這種,對需求的合理性不甚理解,對專案也沒什麼把控,儘管在技能上有提高的空間,也不 是公...

專案管理十日談 序

近期公司停擺,有了足夠的時間,回首進入軟體行業10餘年,大大小小的專案做過多個,成功的專案不多,失敗的專案不少,總結一下,和大家共勉,計畫按如下流程總結,如有需要增加的環節,請大家提要求 1 干係人管理 2 專案目標的確認和演化 溝通管理 3 專案的成本控制 本來不想從這個角度上寫,因為我認為成本控...

web前端十日談 筆記

web十日談 轉行的思考問題 我能做什麼?我不能做什麼?我的優勢是什麼?我的劣勢是什麼?做新行業對我有何好處?換行業會讓我付出何種代價?成功的定義是什麼?學習方法 知識累積 方法一 建構知識面 建立技術體系的大局,然後分別深入每乙個知識點 方法二 先收集知識點,越多越好,最後用線索將這些知識點串接起...