大视角、大方向、大问题、大架构:(结局)解决问题的出发点

为了便于理解建议先阅读前两篇

大视角、大方向、大问题、大架构:(一)信息时代下的管理

大视角、大方向、大问题、大架构:(二)应用的相关问题

信息化所带来的业务的大规模运作是远胜于机器制造时代所具有的产业规模的,请试想一下,一个企业能同时服务于上亿的在线用户的情景,但这并不能说明企业家的胃口到此为止,只要系统能支持,是越大越好。而问题是现在不是没有市场,而是我们的承载能力。这来源与多个方面,管理便是其中一个重要的要素。每个企业都试图能够尽量的扁平化人员组织结构,刘强东说过“战略目的是希望不管组织规模怎样扩大,一定要保证决策层到基层不超过三层。” 这势必要求每个人可管理规模尽可能的大。面对这个要求与挑战,信息化的管理建设首当其冲。由于信息具有快速性、海量性等特性,我们也只能用信息化的方法来管理应用系统本身。

我们需要有能力把分散的、独立的领域统一起来管理。我们需要打破领域信息异构的坚冰,使用一致的规范来统领这些系统,否则企业的规模将难以进一步的扩大;否则我们前面所阐述的问题将始终困扰着我们。我们要编织一张网来渗透到所有的应用系统内部,就像神经系统一样将他们牢牢的、有机的凝聚到一起。为了方便起见,我们暂且叫这样的新的信息管理系统为神经系统。

出师有名,我们需要一个信服的理由来达成统一。如果实现“统一”我们经获得长远的利益这个毋庸赘言,那么我们要统一哪些内容呢?第二章中我们将了好多的问题,而所有的问题以应用来展开,所以我们找到的统一要作用的“体”。但我们并没有回答要统一哪些内容。我们关注了关系、数据、集成、资源等等,除了它们目前不能很好的完成“任务”外,好像也没有什么对本文有价值的需要去统一的内容了。

我们再从另外一个角度来看。如果我们站在企业外部简单的看企业,我觉得只有两样东西:服务于市场的业务和维持业务运营的资源,即一个出口一个入口。而业务是所有资源为之付出的核心,应用系统自然也是因为承载业务而存在。因此上面的问题有这样的答案:我们管理应用这种资源对业务目标的贡献能力,因为应用是一种高级资源,能够牵一发而动全身。请原谅,这里回避企业经营模式创新或者新产品研发等其他问题,这里只研究信息系统背景下目标与资源的关系,而且这里不讨论个体效率,而仅仅讨论协作效率。

应用是各领域目标的承载着,如何能够将所承载的目标明确的体现出来,直接影响到协作效率,这一点从第二章的两张管理关系图上可以清晰的看出来。这里的明确,不是书面上的,也不是设计上的,而是由系统运行期间主动报告“我对某个目标达成了多少次”等类似的具体的、信息化了的数据。只有这样应用系统才具有优秀工作者的素质,信息化了的工作成绩才能被神经系统及时处理。而一个“含蓄”的应用则可能需要通过它的业务产物在数据仓库里分析一下才能得到。两者对管理的优劣足以显现。

任务

目标是比较虚的,我们在运作时会分解成业务或任务或职能或其他名称等,而应用则经常以业务或职能来命名。这是直接体现应用价值的方式,既我是什么,而不是我为什么。这没有背离其隐含的目标性,所以我们在做管理时要处理好两者的关系。为了方便后面的理解起见,这里用任务来代替目标。为了让应用明确说明他们正在做什么任务,我们需要在全局范围内对所有各个领域的任务进行统一编码。并且我们需要充分细化这些任务的定义。只要存在一个潜在的有意义的一个点,我们就需要对它进行标记,尤其是用于协作的点。这一点非常重要,因为这是“肢解”技术屏障的利器。请注意“肢解”一词,我得强调一下。

应用的关系一节,我们提到不同领域间对业务理解不一致的问题,一方面是各方对业务细节无能为力,另一方面是研发“肆意妄为”。而任务的细层次定义便可以有力的“肢解”这种局面的范围和影响。因为经过一致编码的任务,无论业务团队还是技术团队或是其他相关团队都会一致理解,沟通顺畅(我说的是不会跑题)。通过肢解,我们的管理可以渗透到以前我们无法到达的应用系统的内部任何一个点,而不再用关心应用、接口叫什么名。当然我们需要一个前提,应用必须以明确的形式,正确的报告这些任务的数据。

对任务命名的信息化是非常关键的,它为不同领域的协作提供了基础,使得他们有了统一的认识,为企业资源并行化独立运作提供了重要依据,这同时也是神经系统的信息来源。但我不得不说这是前进过程中最大困难中的一个。因为所有的任务都为一个大的目标服务,这就需要顶级领导的强力支持和强制实施,另外一个难点是需要在软件生命周期中各个环节进行定义和跟踪。基于以上两点注定这是一个长期的过程。

关系

任务虽然可以被独立完成,但任务和任务之间一定有关系,任何孤立的任务是没有价值的。而任务之间的关系则是资源间协作的重要的直接依据,是现代管理中业务流程合理性与资源效率考量的重要依据。表示的越清晰越及时,企业的管理能力就越强。所以我们的神经系统必须能够明确的及时的得到这些信息。

天啊!这种关系多如牛毛,而且关系如此复杂,而且时刻都可能在发生着变化,这种方法可行吗?很多人都会这么叫,可能包括最大的头在内,嘴上不说什么,而心理在嘀咕:“这人太年轻了,还需要历练。”所以对此我也深感压力重大!我必须简化这一复杂性及提高实施的可操作性,我必须谨慎应对,否则我说的全部变为废话,我几年的心血就荡然无存。

我们正在进入最核心最关键的部分。前面提到过任务之间一定是有关系的,让我们来深入分析一下任务之间的关系。先来看一下任务的执行方式,任务不是自己生出来的,他是从上级一级一级向下驱动的,因为我们服务于一个总的大目标。这些任务有一个共同的“根”,也就是说大任务产生了小任务,小任务产生了更小的任务。好了第一个有价值的东西产生了,我们按任务的大小来排列就得到了垂直关系

垂直关系只是关系中简单的一部分。我们如何处理不同领域任务间的协作问题呢?在深入之前,我得先提出另外一个问题:有必要给出协作关系的性质、属性、或者其他一些复杂的关系的修饰信息吗?如果很难回答,我再问这样一个问题,所有管理者都关心这些关系的附加属性吗?回答我估计是这样的,我们只关心其中的一部分,而且大家关心的东西很不一样。好了第二个有价值的定西产生了,我们只需要任务之间“有关系”就行了,这是大家都需要的,至于是亲属关系还是依赖关系还是从属关系等 “过分”的需求就由其他系统来处理吧。

然而更复杂的问题再等着我们:关系可能是多方参与的,我们是否需要将所有的关系方都必须以一个整体来表示?谁来维护这个关系体,并跟进它在今后的日子里的变化情况?我们是否需要一个关系的主导者,而这个关系的主导者又如何确定呢?前一段落我指出只需要说明关系存在就可以了,而无需额外的关系修饰信息,没有额外信息的辅助我们好像无法找到关系的主导者,问题好像陷入了困局!……

我不得不将问题的突破口再次聚焦到任务本身上,幸运的是我偶然想起了“生产线”场景:任务的协作和生产线上不同机器的协作方式是一样的。每个任务可能会有N个上游任务,而任务本身可能再分解为几个子任务,每个子任务可能会有1个或没有下游任务。 应该所有的任务协作情形都可以用其中的一部分或全部来表示。于是第三个有价值的东西产生了:我尝试用“上游任务+下游任务”这种简单的形式表示出所有的协作关系

无论是上游任务还是下游任务,我们都必须按照垂直关系的要求那样来定义。对于上游任务来讲,其子任务不需要清楚地知道下游任务内部的子任务情况,它只需要关联下游任务本身就好,如“上游任务.子任务+下游任务”。而对于下游任务来讲由于不知道上游任务的内部,则可以表示成“上游任务+下游任务.子任务”。然而下游任务要想搞清楚所有的上游是困难的,尤其是公共或通用应用(这可是最容易引起老板变脸的重灾区),但上游任务可以毫不费力的知道下游任务,所以我们仍能完全清晰的表示出全部关系来,只要这些任务被统一且一致的定义过。 这样上上段的所有问题得到了完美的解决。

还是任务

好了我们有了明确的任务定义,又有了简单的关系模型,似乎我们的道路平坦了很多。然而我认为还是认为没有对“任务”进行彻底和纯粹的认识。这里有一个疑点,就是关系中含有任务的描述,于是一个看似奇怪的问题在我眼前闪现:我们是否可以将任务和关系一起合并?先假设我们已经合并了任务与关系,我们该怎么称呼这个合并体呢?尽管是关系中包含了任务,但我下意识地认为这不合适,从任务在企业的核心作用上来讲我坚决反对任务的消失。那么我们看一下将其命名为任务是否合适。

从垂直关系上来看,比较直观,可以说这是一个被层级关系标识的任务,既可以被认为是任务。而协作关系却是由两个任务组成的,但我们可以认为它是一个交接任务。于是我们产生了第四个有价值的产物:任务关系其实是也是任务,任务自身可以包含关系,两者是可以合并的,并且可以以任务命名这个组合体。这样就大为简化我们的任务和关系的定义,现在只需要一个编码就能同时表示任务及任务的关系。而且它的形式非常自然,并且防止了生硬的编码形式和重复编码的可能性,同时简化了神经系统的开发和维护等等很多很多工,因为任务是神经网络这张网的核心,而这个网却很大。这也使得任务本身所表达的意义丰富而非凡。

这种编码形式也为多如牛毛的关系提供了分段管理的依据。顶层领导只需要构建和规范顶级编码和他直接管理的下级职能编码,而下级则只负责有限的直接下级编码。这样每一级都不需要管理太多的任务。而上级、协作部门、审查部门乃至基层等都可以方便、清晰、直接的审视职能流转协作是否合理顺畅。千万不要以一种集中的维护方式来定义所有这些任务,否则我们将陷入另一个人为的深渊,因为统一不是集中,但我们可以享受集成的效益。

上面提到的四个有价值的产物能够巧妙的合并在一起发挥作用,极大的简化了神经系统的设计、实施、运营的复杂性。缺失任何一环都将影响可观,甚至是代价高昂与难以维护!这不是偶然的发现,我很珍惜所获得的这种成果,也衷心希望能够帮到各位读者。好了,我可以松一口气了,剩下的问题似乎并不是很困难了,不过我还是简述一下吧。

为任务分配资源

有了明确的任务,接下就需要有资源来执行这个任务,并监控任务的执行情况与资源的效率情况。但一个任务可能涉及到很多资源从而使问题复杂化,这需要对任务进行进一步细化,直到细化到某一任务只有一个“资源单位”与之对应。注意这里用的资源单位是我们想度量的最小单位。在过去出于管理的成本需要,我们不可能将任务划分的很细,但对于信息化来讲这将不是个问题。

与任务的全局性规划与规范对应,我们也需要对所有的资源进行统一标识,否则我们在全局范围内将会感到迷茫。对于资源来讲,也同样存在着很多的附加属性,如上面提到的资源单位到底是人还是机器或是一个小组或部门?这有点像任务关系中的附加属性,但又有些不同,因为资源的种类相对有限,而且对所有领域来讲都需要有效识别所需要的资源。所以我建议将资源进行类似于任务垂直关系的那种按领域范围大小编码的方式进行资源编码,而忽略资源的其他一切属性标识。如果用这样的方式来定义我们的资源单位,我们就很容易从编码上识别人、机器、小组、部门等所有领域范围内的资源。

让我顺便再解释一下关于任务的粒度问题,从上面看任务的粒度是用资源单位来决定的。上一节我们提到任务是内含关系的,用不同的粒度就组成了任务的垂直关系。这个垂直关系的最顶层是终极目标,并由企业高层来把控;而垂直关系的最末端是可实施的职能、任务等,由最基层的资源单位(人或机器等)把控。如果将所有垂直任务的顶层相同的部分依次合并,我们将得到一课树。树干是目标,枝叶是现状,于是是目标与现状得到完美体现,我们可以看到目标变现的完整过程体现。这是一种相当直观的展现方式,管理者每天只要看一下这棵树,就知道业务的健康状况,就会知道问题的症结在什么位置。我敢打赌这远比看各种复杂的报表轻松的多。而且这在技术实现上我想远比其他方法简单的多,因为这个理论就是为了简化而诞生的。这种新型的任务形式所具有的潜在价值就像一颗带来光明的种子即将萌发。

任务的成效

有了任务和资源就开始有行动了,我们不关注如何行动,我们只关心行动的效果。我们始终以德鲁克的目标管理来指导我们的管理,所以我们要对行动情况进行统计,直接一点我们需要行动的数字。是的一定是数字,如果不能形成数字,我想在管理上肯定是一件悲哀的事情。但即使我们把所有行动可以用数字来衡量了,我们还得需要解决另一个问题:一个行动会产出多个不同类型的和形式各样的数字。

就像一个人的健康计数,可能有心跳,可能有体重。但我们可以有两项独立的体检行动,所以再一次细化我们的任务吧,我不允许不必要的复杂性在这个理论里,我需要把所有复杂的事情都变成简单的模式,好让程序简单并高效的复用。请不要担心任务的数量,因为这些细分的任务就像树上的叶子一样由树干牢牢地抓住——垂直关系中的每一段都会有人控制,只要想细分的人不嫌麻烦,而且认为有必要细致的度量一些事情,他完全可以成为树上最茂盛的部分。

价值验证

好了,现在回过头来看我们开篇提出的各种复杂的大问题,来验证一下他是否有价值。首先我们打通了关系,无论在多细的粒度上我们都能够一致的理解,因为我们已经渗透到研发的内部要求他们及时报告我们听得懂或看的懂的述职报告。这是一张灵敏的神经网,一旦有异常情况出现,我们可以看到由精确关系组成的这张网的连动效应,影响的分布区域,影响路线一目了然,我们不需要头痛医头脚痛医脚了,我们的决策将更加及时更加准确。

通过任务的协作关系,当我们需要升级系统时,我们不在需要为谁依赖了我而发愁了,因为她就摆在那里,再也不需要去发邮件问一些傻问题。通过任务的垂直关系,我们可以看到每一级任务的资源支出总量情况,当我们面临战略布局调整时,不管是全局还是局部都可看的清清楚楚,而不用劳驾助理去张罗着收集资料了。

因为我们对任务进行了独立的标识并进行了计数,我们的很多的统计工作可以从海量的业务数据中摆脱出来了,甚至我们可以有统一的报表形式。因为任务是一个宽泛的概念,所以只要是一件工作就可以被标识成任务,而不管是研发的还是质控的还是财务的。这种标准的形式大大简化了各种数据的统计工作,数据部门不用再为异构数据而烦恼,我想他们会从此长寿的。还有个小惊喜,不管业务有多少明细数据,而任务的执行情况只是一个数字。我们又一次从海量数据中突围!

当我们利用任务的关系特性进行密集的织网时,神经网络悄然成型,整个信息系统就像一个有机的生命一样,得到了进化,我们将结束单一“职能”集成的时代,以更加健壮、协调的职能+控制双重集成方式整合企业内的所有系统。这是历史趋势,谁也不能阻挡。谁能适时的顺应这一历史机遇,谁将有更强的控制力。在神经系统的引领下,所有肌肉必将有效的驱动器庞大的机体站立起来跑步前进,跨进信息时代的下一个征途,让我们拭目以待。

全面动态度量

快到本部分的结束部分了,细心的读者,或许你会发现在本章节我们重点阐述的是任务,而应用这种所谓的高级资源在这里没有多少提及,是不是跑题了?答案是否定的,我并没有欺骗你,也许是我的表达能力不强,我没有办法直接说明这件事。可能用HRM的知识可以说明这一问题。在HRM中,人的价值是在任务中体现的。而在这里应用会报告它所执行的任务情况,其道理是相同的。我们必须以任务为核心来统领资源的调配,而不能把任务抛到一边来直接衡量应用这种资源。

前面我们所称呼的神经系统,不过是为了论述上的方便。如果映射到管理系统里来,从业务上讲,它应该被分成度量和决策两个部分。本人自知不敢挑战人类的决策智慧,充其量只能充当为决策者提供数据的小角色而已。即使是这样,要解决如此多的问题,仅仅依据这里提到的内容还是有很多不足之处的,但这些关键的理论会为后续的工作提供莫大的支持。我们还需要有一套完整的与之配套的方法规范。以帮助将这一理论落实到位,那就是本书的第二部分——《全面动态度量》。

另外这里的理论还不完整,缺陷一定是有的,我想只要您能够树立起对应用的资源意识及充分认识到资源管理新秩序的必然性我就感到非常安慰了。所以我决定留一些内容给《全面动态度量》,以防止她读起来无趣。信息化正面临着下一个大的历史发展机遇,而《全面动态度量》将是一个勇敢的实践者,我想实践者是有机会体验一下《信息时代下的资源管理新秩序》是什么样的感觉。

 

                                                                                                作者:李学斌

                                                                                                 2012年11月1日

posted on 2012-12-26 11:28  李学斌  阅读(2473)  评论(0编辑  收藏  举报