第30部分(第1/4 页)

没有足够的信息来了解他们是否在遵循相关的业务规则。例如，该经理有干这个工作的预算吗？该经理愿意给这个项目批准加班工资吗？此外，招聘经理无法容易地了解到某项工作合适的小时工资是多少，或哪些有资格的人员能应聘。除非招聘经理心里已经有一个具体的人选，否则我们就没有一种容易的办法来找出一种可能的资源，不管这个资源是一家公司、一个介绍所介绍来的临时工，或是一个独立的承包者。我们为了正确的预算，需要一种自动计算公开招聘全额成本的方法。我们决定我们需要一个新的灵活软件解决方案。对每一个临时工，我们都必须保证他有一份公开写好并签名的合同。合同一旦被批准，那么这个人的卡式钥匙、电话和上网权利必须在48小时内准备好。用户必须能够容易地创造相似职务的多重相同申请，当您准备一个大项目的时候，这是一种典型的局势。当承包者工作时，经理们需要一种简单的方法来确认工作时数、支付工资级别，以及在采购订单上的余额。当合同终止日期临近时，招聘经理需要被自动警告。经理需要能自动地延长该临时工的合同，但条件是预算还有剩余，而且这个人为微软公司工作的日子少于连续的340天。当终止日期到达时，这个人上网、上电子邮件、使用公司电话和房屋的权利就必须停止。

我们的新过程必须支持变动，但又不能阻碍工作。当一份合同准备妥当时，假如审批经理不在，那么招聘经理则必须能够把合同转到另一个有审批权的人手里。假如在工作分派期间内经理或成本中心有变动，我们就必须能容易地重新分配该项成本。职业介绍所应能自主给临时工小额加薪，但是大幅度加薪则必须得到招聘经理的同意。

决定是否集中管理

一种方法就是创建一个巨大的单一应用程序来处理所有这些需求，即所谓的“大程序法”。我们有一次就这样设计过一个应用程序，是用来使我们内部的十几个服务组织——图书馆、保安、饮食、出差、公司仓库、公司信用卡集团和其他组织等——能跟踪雇员请求并做出反应的。最后这个项目是我们所取消的少数项目之一。各个群体的需要是很不相同的，而商务规章又太复杂，一个应用程序处理不了。我们花了那么多的时间来使这个系统运转起来，可等我们完成的时候，需求又改变了。我们接受了一个重要的教训：很少的公司应用程序需要“集中”。我们让每个小组自由建立自己的申请系统。通过缩小解决方案的规模，我们缩减了大量复杂性和开发时间，今天所有的内部服务小组都有自己的“申请”应用程序，他们每隔几个月就改进一次。它们都是无纸过程的极好例子，这些过程节省时间，使得跟踪优质服务的提供更容易。

我们避免内部应用程序冗长的开发周期。太多的时间消耗往往使优势失效，而商务需求同时又在发生改变。更小的、非集中的过程通常是最好的。只有少数的应用程序，例如我们的财务报表系统，需要集中化。我们在承担了内部其他商务解决方案的同时，一直保持小规模的小组和项目，心里记着我们生产开发小组的座右铭：“及时交货是我们的特色”。

在检查对临时工的管理时，我们想避免一种单一的办法，但与此同时，又不要弄到未了有六七种互不相干的应用程序，不能组合在一起来刨建一个总体解决方案。我们的战略就是，创造一系列模块化应用程序，从开始设计的时候就准备把它们的数字数据互相链接起来。

我们主要的工具就是Ms　Market，即我们内联网上的公司采购应用程序；Ms　Invoice，即因特网或称外联网上的一个网址，它使我们的承包商和其他人能用电子方式递送发票；还有我们的SAN系统，它处理所有的后台财务来往。由于我们已经有HeadTrax来管理人事，我们就把它当用户界面来用，不管哪一个应用程序实际上在幕后“拥有密码”。用户只要简单地在HeadTrax上点击某个特征，正确的应用程序就会开启。

承包过程从Ms　Market里的数字采购开始，我在第三章中已作过全面描述。创建。雇佣和管理临时工的步骤与HeadTrax为管理正式员工的电子控制功能十分相似。MSInvoice是便利于电子传送发票的，也提供控制功能来帮助招聘经理和销售商（译注：此处指提供临时工的机构）不超过预算。在每一张发票上，招聘经理都有一个链接以查看采购订单上的余额。销售商能看到他们的哪一份账单与哪一份发票匹配。假如一个销售商企图送交一份比采购订单上的余额更大的发票，那么这份发票就会被