爱吱声

标题: 漫谈CRM(二):被误读的流程银行 [打印本页]

作者: 河蚌    时间: 2012-3-10 22:27
标题: 漫谈CRM(二):被误读的流程银行
      现在银行改革领域,谈得最多的是两个概念,一个是以“客户”为中心,另一个则是流程银行。而有很多观点,甚至将这两个混为一谈,认为流程银行就是以“客户”为中心重新打造银行组织。但俺认为,这一种最重大的误读。
+ p) B5 ]- _* }2 S" e  T( d. R      流程银行的核心不是客户,而是产品。与之相应,银行的业务核心,不是客户,也是产品。银行是企业,企业的运作核心,不是“客户想什么我们卖什么”,而是“强化自己的核心产品,向固定的市场推出我们的产品”。所有的将以“客户”为中心,作为流程银行的本质的说法,都是经不起实践的推敲的。& G% i% U! ?5 s7 a8 a( P  ]
       所谓流程银行,实际就是生产线技术在银行业务的应用。所以,不要人云亦云地说什么,以前的银行是“部门银行“,现在的银行要做”流程银行”,这是个完全错误的说法。部门是任何企业的基本组织单元,无论是不是流程银行,银行都要按“部门”来建立组织架构。
( A9 {7 I- Y" _( C+ ?      实际上,与“流程银行”相对应的,是“条线银行”(或者称为条块银行),所谓条线,是银行中以业务来归纳的一系列部门。由于银行近二十年的业务迅速扩张,实际上,银行的组织结构一直是被动的去适应业务发展,即每增加一种新的业务,就会组建相应的新部门去管理,这一部门自总行到网点都会体现出来,从而形成明显的条线特征,即各条线相对独立,各自办各自的业务。
* y: H0 s2 b0 Z2 a$ Z      在现行的银行部门设置中,可以看出明显的业务分割特征,比如现有部门包括有电子银行部(主管ATM、POS等电子业务)、网银部、信用卡部、个人银行部、公司业务部、房地产信贷部、国际业务部、资金运营部(主管票据)、投资部(主管债券投资)、信贷部等。
9 i- n: O; N3 r6 I* L      部门按业务来设置,出现的最大问题,就是各业务之间,都是独立运作,从客户营销到业务办理到审批、审核,各部门都要设置岗位,从而形成大而全、小而全的局面。实际上,无论是客户营销,还是后台审批,其实都可以由统一的一批人来完成,而不需要各业务部单位设岗。而即使业务办理,实际上,也可以合并。
0 [3 m8 ]! N7 x9 x( w8 [      其实,流程银行,就是因为上述的部门分割造成很大的资源浪费,让银行管理者觉得,应该打破上述的条块分割,以产品为核心,去分析每一个金融产品的办理过程,在精细化每一种产品办理流程的基础上,对银行的部门、岗位进行重新设置,从而达到银行资源配置的最优化解决方案。
& Q# t7 T! x( D- g# z5 b      而在流程银行的分析归纳中,最显而易见的合并领域,就是客户营销领域,在银行现在的营销客户经理中,存在着严重的划地为牢,比如客户经理分为对公、对私、信用卡、票据等多个职责类别,而每个职责的客户经理只能去管其职权范围内的业务。
+ g/ @7 F- \& c, x8 Y      因此,银行在客户营销领域的改革,也是银行经营体制改革的重头戏,而在这一领域里,最大的理念,就是变以“业务”为中心为以“客户”为中心。虽然营销是企业的生命线,但营销领域的以“客户”为中心,决不代表银行整体是以“客户”为中心的。0 T, j0 G$ ]  J( @. S( J* e. h
      国内银行界最大的问题,就是已经搞不清楚银行是一个企业,而银行的经营应该以企业为目标模式,可惜大家更多是听国外专家的忽悠,而且,这些忽悠的专家还不是银行业务专家,而是IT咨询专家。
作者: 就爱抬杠    时间: 2012-3-11 17:27
流程银行是个大概念,应用起来恐怕还得具体情况具体分析。个人认为,所谓“以客户为中心”自然是梳理为客户服务的那部分流程。即使我看到的流程银行资料,也没有说全部都要面向服务客户的。当然这方面我是外行。我作为企业的IT,面向我的客户服务的部分,我们是肯定要按照“以客户为中心”的原则来重新梳理的,而我们后台怎么去管我们自己的主机数据库,这和客户自然没有直接关系,但是和要向客户提供的服务水平有很大关系,起码我得能说清楚。所以,间接的来说,也可以说是按照“以客户为中心”的原则来改进。除非像银行,从持续性上来讲,基本不用考虑服务水平和成本的关系问题,直接提供最高水平就是了。
作者: 河蚌    时间: 2012-3-11 20:05
就爱抬杠 发表于 2012-3-11 17:27
7 @7 F4 X$ J1 c) r流程银行是个大概念,应用起来恐怕还得具体情况具体分析。个人认为,所谓“以客户为中心”自然是梳理为客户 ...

7 M! M0 G3 z4 L9 d( _: I      呵呵,现在特别希望能有人一起来探讨这个问题。这篇其实是由你的那篇IT管理中提到的概念而由感而发写成的,写得很零散,主要是想谈一下自己的一些不成熟的思路。
5 N% O/ D- J' p1 I& C5 l8 ^/ P      流程银行,是现在银行IT建设中一个很热的话题,说什么样的都有,我也收集了一堆的方案,一有机会还会和银行里的人讨论这个问题。可以说,到目前为止,无论是方案,还是银行内部的人,都没有一个统一的说法。其实一开始,我都不明白“流程银行”到底是一个什么概念,因为不同的公司方案里面,有不同的说法,但这些说法却十分可疑,因为都只是说某个侧面,而且还有买私货的嫌疑。
( W- U5 ]- G# J/ E      研究时间长了,才明白,到底流程银行是个什么概念,而且明白银行到底要用“流程银行”来做什么。其实就是想从银行的全局角度,对所有的业务流程进行梳理,该优化的优化,该合并的合并,通过这种思路完成银行的业务流程的再造。
8 @0 p: V' U8 d+ [) w; W' j- q      在我看来,“流程银行”并不应该是科技的概念,就象平衡积分卡、巴塞尔协议一样,都是银行业务的范畴,是银行总体管理体系再造的范畴。它们的实行,应该成立超越于部门的专门的委员会来负责相关的实施细节。只是大多数银行的业务管理层,对上述的概念并没有深入的了解,而科技部门则是与外界新知识接触最多的部门,因此将此任务交给科技来解决。这也就是我说的,科技部门在银行(大企业中)定位的改变。. P# F1 z: W+ }- a1 U, \
      但,科技部门接受了这个任务,就应该脱开科技的视角,而要用业务的视角来看待这个问题。而什么是业务视角,其实就是说,如果业务流程中,完全去掉IT技术(主要是网络),应该如何开展。应该说,在你的回复中,可以看出明显的科技视角,将流程分为“客户服务”(前台的)和“主机管理”(后台的)两部分。而如果我们真正按业务视角去看,科技应该是透明的,也就说“客户服务”是有的,“主机管理”是没有的。
$ o6 F- P% k4 X" t- z      基于业务视角,其实也有前台的和后台的区分,前台仍然是“客户服务”,后台则是“业务运营支撑“。而如果从通用的企业生产运营的角度来看,则所有的企业流程,都可以分为进货、生产、库存、销售四个环节。其实银行也可以看作一个特殊的企业,只是在它的生产流程中,跑的都是钱,因此,相对于实体企业,每一种产品都比较简单,但同时,相对于实体企业,它可以有多得多的产品。1 ^, ?0 ]6 \9 ^9 k" q' N5 n
      银行与实体企业的这种区别,现在也已经明确化了,这就是现在已经被广为人知的实体经济与虚拟经济的区别。作为虚拟经济的代表,银行实际上是通过不断变化出的金融产品来获取利润的,而这种产品创造的轻易性,造成的一个错觉就是认为,银行可以按照“客户想什么我们做什么”来经营,这就是以“客户”为中心概念的由来,而不必遵从“我们有什么就去卖什么”这一实体企业的概念,后者的概念实际上是以“产品”为中心的。
- c& p' k) ^+ h: |) K. s1 ~      流程银行,其实就是梳理银行的整体业务运营流程,由于银行产品的虚拟化成分很重,金融产品更多是某种基础概念的衍生,并无核心技术来支撑,因此造成了银行经营中“客户”因素十分强大,甚至压倒了“产品”因素。这也就让很多人认为,银行的业务流程应该以“客户”为中心来规划。但我们必须明确的知道,虽然银行单个金融产品经营中,“客户”因素很强大,但如果将银行所有的产品综合考虑,就会发现,其实“产品”因素仍然占有绝对的比重,这从银行的后台并不临客的业务支撑人员(有时称为业务内勤)的数量就可以看出来。2 z4 F$ L0 b9 j4 W: n7 h8 Q
      因此,如果按“客户”为中心来梳理银行流程,只会造成银行业务流程重组的偏离,因为客户在银行的业务流程中的某些环节是缺失的。而以产品为视角来梳理流程,则会发现对产品的运作贯穿了业务流程的始终,采用这种方式,更能够完成流程中各工序的归纳和组合。8 |, W0 \' x( W' \* t* U- b
      而“客户”因素占主导的,则是银行总体业务流程中的销售环节(再加进货环节),也就是所谓的企业的对外营销环节。对于这一部分的梳理,其实可以理解为将客户当作一种特殊的产品,对其进行有效的加工的过程,由潜在客户变成VIP的过程。此部分主要采用客户生命周期理论,也就是我们经常说的客户关系管理。+ ?+ I1 K  ?7 {% L! ?
      上述的内容,是最近研究的一些心得,还不成体系,比较零乱,希望能够一起来讨论,将此部分变得更为清晰一些。
( _" B; Y, }- Z$ G- m& v+ g# T! I# o
作者: 胖子    时间: 2012-3-12 14:51
河蚌 发表于 2012-3-11 20:05
/ Z8 [1 b( D, O& @7 _* U8 T7 s呵呵,现在特别希望能有人一起来探讨这个问题。这篇其实是由你的那篇IT管理中提到的概念而由感而发 ...
5 N/ g6 Y" E( F7 h! U- l
蚌兄此论可谓高屋建瓴,很精彩!" Z4 R4 w- y4 {. q& ?- O/ c
0 V) n. Z: b0 t( I
也来和一下自己的看法7 x& D% r( s# ^7 W0 ]% L1 A" v7 d

2 a% \: ]& }8 J0 x( S' T前两年,受金融危机影响,很多企业都把着眼点从业务扩张转移到业务流程再造(BPR),在进货、生产、库存、销售几个环节中,每一个环节都是深挖的对象。甚至,某些很强势的企业,还可以把这一活动扩展到整个产业链。& O- R1 K9 g; f/ k: Y

8 l, f. S2 l  w0 ?" C" T  V& l在这个大背景下,出现了很有意思的现象:无论是仓储物流、财务、还是生产,每个环节的优化都至少有一个落脚点是对IT系统进行enhance;而且,在项目进行的过程中,IT部门会逐渐成为项目的协调者和实际推动者。' Z( V) S: q' a7 i
" J. B" q3 `0 J6 ~+ ]7 _2 f7 M
究其原因,一点浅见如下:
5 `9 E* B; L# X1、企业内部环环相扣的业务活动中,业务部门难逃各自为政的思维局限,组织壁垒也是强力阻碍。而IT&IS,恰恰是每个内部利益团体的结合点;& c1 H: g- C8 l. @2 {: y
2、另一方面,从实际的业务操作来说,负责业务支持的IT工程师很可能比用户部门的员工更懂具体业务间的内在联系----比如一个优秀的SAP工程师几乎能胜任财务、采购、仓储各种岗位,具有全局观。
* r' ~6 H" v+ j( I( ]3、无论是内部支持团队还是外部服务商,IT部门总是超然于传统业务组织的,没有直接的利益竞争。
' j8 V, p, G3 Q) D3 X
作者: 河蚌    时间: 2012-3-12 15:14
胖子 发表于 2012-3-12 14:51
3 d8 Q* r) I2 g! K, W% D. T% a蚌兄此论可谓高屋建瓴,很精彩!
- p& i6 h3 ]7 y5 _# q& G1 j# T4 ~7 m* Y( d2 L
也来和一下自己的看法
6 A' ?9 X4 S3 J# q4 N
      确实如胖兄所说,由IT科技部门进行流程再造规划,似乎是唯一的选择,因为它是唯一的了解业务同时又与部门利益无关的部门。
# e7 a* s+ q8 a7 V- t1 [; F      但现在在实际执行上仍然是一个困局,就是正因为IT部门超越于业务领域,所以,IT部门的话,也没有人听,没有人去当真,IT部门在会上谈规划,业务部门会以各种实际的问题来进行质询。IT部门的员工,虽然对流程很熟悉,但是对于实务并不熟悉。
8 a- w/ e  X1 c" F      这个可以举一个银行的简单的例子,比如银行汇兑,科技人员可以讲明白,每一步是怎么走的,但是当问到这个汇兑的帐,要走什么科目时,大多数都会傻眼。这就是两个不同口径的部门的工作性质的不同所造成的。* t  c4 _9 d9 r' o' R
      但,不管怎么说,这总是一条路子。企业的整体流程再造本来就是一个十分困难十分困难的系统工程,但不管怎么难,总是要往前走的,即使步子小,只要知道,我们在正确的方向上,那就足够了。- H* U1 J, @( `! ~3 g  v/ N6 I
      我觉得,要想让这件事情进展下去,不单要IT部门参与,更要IT部门摆正自己的位置,将自己当作一个战略规划部门来看待,同时加强与业务部门的交流。这个方面,我在答“就爱抬杠”兄的《运维管理杂谈二--什么是客户》时,谈了自己对于IT科技部门与业务部门间关系的一些看法。
$ j* O) Q/ t( s/ p- r  a' M
作者: 胖子    时间: 2012-3-12 15:33
河蚌 发表于 2012-3-12 15:14 ! w9 _! ?: z9 t3 g$ [7 A5 U/ S
确实如胖兄所说,由IT科技部门进行流程再造规划,似乎是唯一的选择,因为它是唯一的了解业务同时又 ...

% I5 V- w( z( w( ]' W没错!我们的讨论都是在比较理想的情况下,且从IT从业者的视角;蚌兄指出的问题,已涉及到企业管理运营和文化制度建设层面了。
' p8 i/ }1 @- q$ D1 }. r
' E! a! e8 Z, {; Q知道了正确的道路,就需要强有力的推动。+ V, m8 s* Z# K2 d$ A9 x0 @
好在BPR项目通常都是至上而下的层层指标分派,业务部门迫于压力多少也会配合。当然,一个灵活且具有话语权CIO是能大幅提高最终实施效果的。
作者: jerrod    时间: 2012-3-13 16:10
crm对于操盘手就是臭狗屎,个人见解。啊哈。7 v8 O* o" B  A& S
8 }8 o8 |" @( s7 P$ }- A
crm对于企业来说,不了解,反正天上全是牛在飞。( H/ M# t0 D/ g3 L! I, A+ A+ @

. ^) \0 A- E2 g! l/ o9 k4 Xcrm对于券商,不得不怀疑是利益输送,而且存在风险隐患。' q& @( n9 }0 D) f+ ^

* D+ j4 x  w* h+ U$ ~3 o* l% b7 W以上为个人见解。勿拍。
作者: 河蚌    时间: 2012-3-13 16:22
本帖最后由 河蚌 于 2012-3-13 16:23 编辑 " B) {9 I6 a2 W3 d' L
jerrod 发表于 2012-3-13 16:10 3 \' i# m+ v2 L% I
crm对于操盘手就是臭狗屎,个人见解。啊哈。5 ~  ]6 i) l+ v& ?
" ?* P3 k& e8 `# N
crm对于企业来说,不了解,反正天上全是牛在飞。

* v, K* m% S' e+ ^  A8 M  C. D" H7 u2 s/ A& s( m
      除了第二句明白外,其余的都不明白。操盘手用CRM干什么,还有券商用CRM干什么。对于第二句,那么就得这么说,不管天上是不是有牛在飞,但CRM是实实在在的需要。我们在研究生院里,就是希望每个人说出自己的心得,哪怕是不成熟的也一样可以讲。研究研究,就是不要对一个东西只下结论,而不讲任何理由。' P* I- {' m' z
      一个大型企业,不去分析自己的客户,不去管理好自己的客户营销流程,那么这个企业就是一种家长制+个人控制的企业,如果换一个不强势的领导,那么就会处于放任自流的状态。虽然这种全面的分析很难,但就因为需要,所以我们才要去一步步地去做,做出实绩来,在实践中总结,然后再进一步前进。3 R5 W$ g! T- `. @
      只要自己想做一件事情,觉得这件事情有意义,就不要管外界的环境如何,也不要管别人做的是不是对的。成功是做出来的,不是喊出来的。
3 c2 ~  T  Z+ z+ s5 g( d      在这个世界上,喷一件事情,是最容易的事情,这个世界上也最不缺少批评者。但当你不加思索的喷一件事情的时候,你也许失去了因此而锻炼的机会。而当你不加思索的喷所有事情时,那,我想,一个人也许会永远失去前进的动力。
+ a2 N4 T0 f, a) Q; k
作者: jerrod    时间: 2012-3-13 16:43
本帖最后由 jerrod 于 2012-3-13 16:46 编辑
& a" _: y  T1 Z; o
河蚌 发表于 2012-3-13 16:22
, o: u* ?: v; t# _' O0 Q' y除了第二句明白外,其余的都不明白。操盘手用CRM干什么,还有券商用CRM干什么。对于第二句,那么就 ...

9 g& k$ Q; X' ]8 h) z+ v* U! O) o, Y, i0 k
首先,我必须声明,您说的非常在理,我非常认同。3 c# M/ x+ Y5 a) Y

1 k, c4 [& W$ W3 i3 P# U% x8 R; i我是券商的,那么我来说一下我们上crm的得失。以提供信息为我的语言道歉。希望您能接受我的歉意。
& @) O1 G5 c& ^4 J8 l  |# j& `
; l5 z+ b+ f+ x: p2 Q先说得。$ L. N  H5 J8 @) i/ [7 m
7 h8 j# q4 R; [  F+ f
crm的好处的信息整理,收集,散发。这样做,信息传递的效率高,损耗小。9 G* A2 Y" l; S4 l

# d; T0 W3 z, }" W0 D# J6 Y再说失。7 S. M" l' _4 z) A2 t
' j! ?8 k3 P7 [  W. d3 X
一。信息真伪度。二。信息时效性。三。信息有效性。0 S. ^+ p% e+ h

7 w- e" L: X: X4 D6 U谈谈我的经验。! r: f3 a/ h, {

7 b) Z& X8 ?) b( ]0 r0 P& rcrm收集的信息,存不存在为权力寻租提供了便利?存不存在只是为了上crm而上crm?对于crm发挥的作用是怎么考核的?7 ~5 f+ w0 r, |

  O. [% C/ v/ U, \6 T* q  a我对我们这噶嗒crm的态度是,画蛇添足,结果搞成四脚蛇了。
3 z9 ?* }  K# ~% w" t5 }: d; Z9 O( ^1 s1 V5 X
最后来一个总结性的,我的逻辑比较保守,就是机器或者程序在资本密集型的行业,根本无法替代人。也就是说,在资本密集型行业上crm只是为了方便管理而已,真正开疆拓土的是人。
9 H5 p# b2 r3 F) p& s- x7 U/ t- c3 x( ?6 O- o
期待您的回复。共同探讨,共同进步。- P% i8 r( P' x# u1 ^0 b

' m; r% {$ l# K/ l5 B/ Y1 c1 v
作者: 河蚌    时间: 2012-3-13 17:14
jerrod 发表于 2012-3-13 16:43
+ X0 q- Y6 s2 j首先,我必须声明,您说的非常在理,我非常认同。
9 D7 W. Y2 n$ I- D1 a3 V. ]& A7 ^& \$ z) F8 x3 t7 \  X
我是券商的,那么我来说一下我们上crm的得失。以提供 ...
( k9 ?5 J4 O- m. c$ o
     是这样,CRM在银行,分为分析型ACRM和操作型OCRM。
" {+ g4 T  ?1 _     分析型CRM,又分为两块,一块是客户个体的分析,一块是客户总体的分析,也就是基于营销团队视角的分析。在这两个中,第一个客户个体的分析,主要是客户单一视图、客户业务统计、客户度量、客户评级等,而第二团,则主要是做营销团队所管理的客户的结构、排名分析,进一步做出客户的群特征分析,以及对团队的营销业绩的评价等。
4 x7 B4 \4 I5 U: w7 x: h( l      对于银行而言,实际上客户个体的分析是十分实用的,因为任何部门,都可以通过CRM系统查到某个客户的相关情况,这些客户的数据,是银行日常经营活动中取得的。行内业务信息是非常准确的,客户自身的信息,只要是信贷客户,也是很准确的。CRM所起到的,就是一个集成信息的作用。
4 b" _  {# T( f) K9 s% e      通过客户个体分析,可以对客户的信息有个全面的了解。这个在管理上是很有用的,几乎所有的营销人员,都会通过这个来查客户的情况。
8 d+ n) B7 s% h4 X      另一个则是客户的评价,实际上,大多数客户的主体信息不全,评价是没意义的,但是,那些好的客户,往往也是信息比较全的。所以可以通过评价,找出来那些好的客户,用于新产品的定向推销。这个是系统增殖的部分,但用的不好。! p1 ]( f- N4 c% ]' T
      而同时,客户总体分析这个,主要还是对客户经理的营销业绩进行评价,这个也比较实用。
, F* v. }& D+ h- H      操作型的CRM,主要是做客户营销流程的控制管理,包括客户日常维护、营销团队管理、销售项目控制、计划跟踪等。这个模块,实际上已经切入到客户经理的日常工作层面了,也是目前很多银行想要的东西。
, t: F) F1 x7 i3 l2 X9 V& H      银行和券商可能不一样,银行所办理的业务,涉及到生活的方方面面,经过几年的积累,会有很多记录,通过这些记录,可以找出客户的秘密来。 所以,CRM在银行还是很有市场的,当然,也引得满天的牛都在飞。不过对我而言,我还是希望能做出银行真正实用的东西的。  x3 o- w; a/ \* x# \5 B0 Q

作者: jerrod    时间: 2012-3-13 22:19
河蚌 发表于 2012-3-13 17:14
& _- ^3 d$ U% f; }; e4 h8 z3 o是这样,CRM在银行,分为分析型ACRM和操作型OCRM。0 B; x3 \0 \; i) o2 h" U1 ^0 k
     分析型CRM,又分为两块,一块是客户个体的 ...
1 ?& c" \# F( c+ @7 C3 K
呵呵,所谓不打不相识,交个朋友。
7 X3 P  e/ l- M, r  _; r6 m  C% R4 C+ Z
你可能不知道券商的人对crm这一类的东西有多么厌恶,理由很简单,重复劳动。# H! e$ p. j& T* s9 I) J( d/ W1 c

* t* C8 |8 Y, @1 C% Q0 X2 O' |呵呵,以后多向您学习。
作者: 河蚌    时间: 2012-3-13 23:16
jerrod 发表于 2012-3-13 22:19
, f2 \. g0 G  \  k呵呵,所谓不打不相识,交个朋友。
* c) y" ?% P7 Y+ O: l" W# U6 _/ G% ?
你可能不知道券商的人对crm这一类的东西有多么厌恶,理由很简单,重 ...
  A5 O7 w' S3 H: A' l: h" _, N
为啥呀,券商,用CRM来做什么,不会是要操盘手把客户的各种资料全都录进去吧。- H; ^1 \- {2 M* L0 w$ }" k





欢迎光临 爱吱声 (http://aswetalk.net/bbs/) Powered by Discuz! X3.2