| 在部门范围实现过程优化 | ||||||||||||||||||||||||||
| 摘自: IBM developerWorks China 被阅读次数: 293 | ||||||||||||||||||||||||||
由 yangyi 于 2007-09-02 22:09:00 提供 | ||||||||||||||||||||||||||
级别： 中级 S. E Slack (sally@sslack.com), 作家及业务转型沟通顾问, 自由撰稿人 2007 年 8 月 09 日 网络分解趋势正引领着从部门的角度来说期待广泛分布，但仍然高度优化的组织。但是以这种方式优化的部门对组织总体上有不利的影响。学习如何确定并了解这些趋势所生成的问题和关注点，以便您可以通过有效的业务过程架构将这些分离的要素联系在一起。 管理顾问之间正在争论，各种组织的功能和规程的分权化或集权化是否是达到最大效率和最佳利益的最好做法。近来，钟摆正偏向从计算机网络到部门活动的地理分布，以及设计用来监视的相应的组织结构的分权化。 这并不令人惊奇。现今，随着越来越多的公司都设法建立全国或全球的分布，组织的结构也日益复杂了。不仅比过去更积极地招收最好和最聪明的员工，而且经常特许他们在家中工作，人员活动的范围已经随着更多的行业转入更大规模而增长。雇员极度的多任务化，新的计算机系统都不能提供完全的支持。劳动分工已经分得很细，企业的一个区域处理业务的一些方面，而其他区域处理其他方面。举例来说，阿拉巴马州办公室的 Joe，可能管理呼叫中心，而科罗拉多州的 Sue 监督生产。从事公共关系的 Carol 在她加利福尼亚州的家中利用虚拟专用网络（virtual private network，VPN）进行工作。 20 年前没有被提出的这些问题，现在位于大多数管理清单上的首位：我们应该外包吗？我们应该冗余地构建中心网络吗？应该准许雇员远程工作吗，或者他们应该每天都待在公司的建筑里吗？取代优化业务个体，精明的企业正走向部门业务过程的优化 —— 如果进行了正确的集成，这些过程能优化整个组织。在我们如何 —— 及在哪里 —— 工作方面的这种社会变更已经成为网络分解趋势的催化剂，以及设计用来管理节点的组织结构的分权化。
网络分解（Network deconstruction）可以被说成是许多公司日益依赖的网络的地理分布，以及公司所使用的这类网络中的变更。与此同时，设计用来在这些网络中管理节点的组织结构是职权下放的。这些趋势的结合，以及对组织过程优化的关注，是一些人所认为的新型组织的基础：即广泛分布，又高度优化。 这种类型的组织似乎是幻想的，不是吗？大多数组织都会遇到没有足够的时间来管理中央网络的困难，而且只有很少的一些组织能表现出有效地优化过程的能力。而系统范围增长的越大，广泛分布的必要性就越大 —— 协调整个系统的单个节点是太容易失败的目标了。在这种分布级别上，就有必要尽可能多地优化过程，以确保通过比电线和硬件更多的东西将组织连在一起。 聪明的组织，甚至在组织本身分解和重新分布的情况下，也着重于过程优化。同时做两件事的能力带来了完全的组织优化 —— 两个活动的分离会形成难以处理，无法控制的组织。
工作场所是计算机影响大多数人的地方 —— 而且是过程影响大多数组织的地方。举例来说，如果网络提供所有必要的信息的话，一个拨号给呼叫中心的客户可能首先得到接电话的接线员的受理，而不是转接到专业人员那里。该系统解放了专业人员，让他们从事其他工作，并且加快了客户服务。如果接线员已经选择将客户的呼叫转接给专业人员，那么将会策动一个非常困难的过程。 有效的组织了解，每个运作层次上都需要详细的过程，从营销和销售到生产和分发。非常有效的组织发现，必须跨组织整合部门的过程，以确保不存在缝隙或重叠。更多的组织正在认识到，过程变更可能导致边际操作的改进。举例来说，IndustryWeek 杂志 2005 年调查了 700 家美国厂商，并且发现 80％ 在进行过程改进。 因此，在组织中管理业务过程的概念最终被视为组织成功中的关键步骤 —— 一些组织甚至还拥有专门追踪公司中所有过程和相关软件及硬件的具体业务过程部门。这种追踪是通过各种各样的矩阵和路线图完成的，这可以有助于软件或硬件中冗余的定位。然后，这些信息将被输入到详细的业务过程架构文档中，用来进一步确定过程问题。这种对业务过程的关注使广泛分布的组织能够高度组织化。但是，如果个别部门怀疑，或者反对任何试图获取它们过程的人的话，这些组织甚至也可能遇到麻烦。这些部门习惯于执行它们自己的规则，他们经常不接受整合工作，特别是当那些工作可能导致不让再使用熟悉的工具的时候。
极其经常的是，组织中的部门不认为它们孤立的过程变更会对其他部门产生影响。举例来说，它们可能选择专门为营销处理数据库任务的软件，但是不与销售数据库整合。因此，组织必须治理所涉及的业务过程 —— 特别是那些涉及软件和系统开发的业务过程。 当从上到下来分配性能目标时，部门经理将完成任何他们必须做的事情来确保达到那些目标。未达到的生产目标、无效的营销活动，未满足的销售指标 —— 这些中任何一个都意味着经理的失职，或者整个部门的整顿。不管对组织其他区域的影响如何，精明的经理会快速地学习，优化他们自己的部门过程。 关键的是业务过程的优化考虑到了这些个人和组织的问题。预计一个部门过程中的变更对其他部门的影响有助于确保部门 A 的目标的执行不会以部门 B 的目标作为代价。有效地预计这种影响的关键是询问关于过程变更的问题。如果问题的答案不只一个，那么就加入支持目标或限制，直到在执行阶段不会产生混淆为止。举例来说，如果业务过程变更是打算令销售代表更容易地增加销售量，那么接下来的问题可能是：
很容易看出，为了促进销售增加而进行的过程中的简单变更如何对许多其他部门产生直接的辐射影响。持续地询问问题将意味着最终的业务过程变更可能从“增加销售”变为“增加百分之八的产品 A 的销售量，同时保持所有其他的产品销售都处于当前水平，并且提高四点的收益”。 另一个明显的问题是，如果网络和组织结构已经是分散的，那么谁将会监督每个人是怎样合作的呢？缺少对分布的组织和过程的集中控制几乎注定要失败，因此，高级管理层必须依赖高层次的业务过程架构和相关的业务过程方法来帮助他们不仅追踪具体的部门，还要追踪部门间如何一起工作的整体情况。缺少了这些全局的过程视图，上层管理层可能永远都不会发现使部门在未经检查的情况下运作（不考虑它们对组织的整体影响）过程中的重叠或缝隙。
在分布的组织中工作的架构师，如果他们记得：深入的细节会令管理层看不出较大的业务过程问题，那么他们就可能是组织成功的关键。当然，虽然对于每个过程，在某个层次上进行非常详细地定义是很重要的，但是真正有用的业务过程架构将概括出制定能帮助管理层确保组织目标的实现的业务决策所需的，高层次的过程视图和基本的信息。这似乎不利于架构师身体的每个细胞，但是有用的 —— 不是所有的 —— 信息，这些信息是高层管理层在尝试了解各种部门问题和关注点时所需的东西。 这样看一下：当执行层将业务过程外包时，首要关注的不是外包组织将如何供给人员或管理该过程。相反，要关注的是，该过程是否在产生所需的结果，以及是否会与公司中相关的过程进行交互和是否支持公司中的相关过程。因此，当开发出高层次的业务过程架构时，应该包含这样的思想，上层领导层将会用它替代组织图以了解公司的运作、度量结果，并进一步制定决策。 过去，管理层根据行动过程来决策，然后通知信息技术（information technology，IT）部门，这样才能实现一个计划。有了高层次的业务过程架构，架构师就有能力决定组织的未来发展，而不仅仅是响应组织的需求。但是，在缺少了高层可以审阅的，并且快速了解其所有含义的架构时，该能力会立即丧失。图 1 展示了，最近，为一个全球公司的执行层开发的高层次业务过程架构的实例。 图 1. 高层次业务过程架构实例 
您可以看到，虽然从业务角度看，包含了许多过程，但在这种情况下，对于执行层的关键点是：
这种类型的高层次业务过程架构使人很容易看出缝隙和重叠的位置，哪一个缝隙或重叠令执行层为了组织的利益做出关于过程整合和优化的决策。它可能是着重于部门的范围，但过程不一定是这样。当提到变更、改进，或消除对整个组织有不利影响的部门过程时，执行层比您想象的更易于接受。他们经常认识不到那些过程问题的存在。
在处理您的业务中的网络分解趋势时，不要绝望。广泛分布的组织在未来任何时候都将不会消失。全球化的经济指出，分布和分权化趋势将持续到可预测的未来。有时候，当部门拒绝很好地合作时，您会觉得好像打了场败仗，但是，您对他们个人的问题和关注点了解的越多，您就越可能设计出一个将您组织中完全不同的要素集成到一起，且满足他们需求的业务过程架构。用您的执行层可以理解的语言，对他们描述您的目标，您将会得到意想不到的资源和支持。 学习
获得产品和技术 讨论
原文链接: http://www.ibm.com/developerworks/cn/architecture/ar-procopt/index.html | ||||||||||||||||||||||||||
