未来时速-第36节

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！


保琀eadTrax每个月处理大约8000次人事变动。不再需要人力资源部评审的批准手续占所有人事申请的90％，在24小时内就反映在这个系统中了。人力资源批准手续要花更长的时间，这是因为一些与技术无关的过程，例如给一个要离开公司的人举行的辞职面谈。
　　HeadTrax使商务和人力资源经理们能够在任何时间审查所有未解决的人事变动，从而增进了他们的责任感。一个商务经理通过清点他小组里的人头数，能够了解他的小组成员在岗位缺人时干得如何。如果这个经理发现他的一个直接下属经理比本部门其他经理更缺人手时，那么这个高级经理就可以调查一下，看是否需要花更多时间雇佣一位经理来招聘人员，或者是否需要从公司的招聘小组得到更多的帮助。
　　负责人力资源的经理们认识到，把时间花费在批准每一次常规人事变动上，并不是最明智的。相反，他们开发了一个电子工具来处理日常业务，并收集数据做人事管理趋势分析。一个高级人力资源经理可以用HeadTrax的审计功能来查看所有被拒绝的人事变动，看是否有个模式显示出经理们需要在人事问题上接受更多教育，或HeadTrax应用程序是否需要有附加的一些功能。人力资源部也可以分析一个经营单位是否比其他单位有更高的人员流动率，还能看员工离开公司的理由中是否有个共同模式。HeadTrax不仅为我们的商务人员提高过程效率，而且使我们的人力资源人员能重新定义他们的作用。能立即看到关于调动率或员工流通率这类事情的数据，其价值远远高于降低的成本或节省的时间。
　　认准任何过程首要的、中心的目标，这就是开始解决过程问题的办法。不管是生产过程还是内部商务过程，其目标都应该永远是根本性的简单化：让最少的入做最少的交接。要优化一个书面过程是极端困难的。数字技术使开发更好的过程成为可能，它不是让您停滞在陈旧的书面过程的小变动上，那只能让您做渐进性的提高。真正的过程突破来自认真考虑的解决方案与数字信息流的结合。
　　利用数字过程解决难题
　　在微软公司最棘手的商务过程之一就是雇佣、管理临时工以及给他们付酬。
　　对于一家有许多项目、产品投放市场时工作量达到顶峰的公司来说，管理临时工是极为重要的，临时工帮我们处理高峰期工作负担，从开发、测试、营销到行政支持工作，包罗万象，无所不有。在我们对临时工的使用中，有5组人员需要协调好：（1）临时工本身；（2）临时工为之工作的110家机构；（3）在各个部门里使用临时工的经理们；（4）我们公司内部的临时工管理小组，该小组管理我们与临时工介绍所的关系，跟踪临时工每小时的工资率；（5）公司采购部，实际上是它们给临时工支付薪水。
　　我们的业务问题是多方面的，不仅仅是因为跟许多不同的机构和临时工签约购买服务要牵涉到大量文件。我们在保证连贯的签约过程，按恰当的小时工资招聘合适的人员，不把临时工使用在大多的连续项目上或在一个项目上使用临时工大久，以及决定什么时候把临时工转变成正式工等问题上都有困难。
　　几年前制订的一个雇佣人员的政策，在使用临时工问题上建立了严格的指导方针。按政策规定，所有临时工都应通过职业介绍所来雇佣，任何临时工都不得在各种综合项目上工作超过340天，他在其间应中断服务至少31天。但是书面的过程使得签约雇佣临时工的经理——他们中许多人都是新到公司的或新担任这个职务的——很难保证遵循这个指导方针。由于我们的招聘经理们都有事情逼到头上来才行动的特点，所以我们满足各部门的需求和防止犯错误的唯一办法就是把许多人投入到要解决的问题上去。人力密集型的过程并不使我们感到高兴。
　　再有就是，书面过程并没有给高级经理们解决预算问题。因为许多经理都雇佣了临时工，以及临时工经常在多个项目上工作，各部门的高级经理们没法掌握被使用的临时工总人数，也没法掌握临时工工作的小时总数。我们无法前后一致地预测雇佣临时工的成本。各部门经理从财会部弄来的关于人数、小时数和成本的财会数据总是姗姗来迟，或只是估计而不是实际的小时和成本。给临时工支付的工资在有的月份升得很高，有的月份又降得很低。
　　在一开始的时候，我们以为这个问题是出在财会部的过程里，但是当我们分析数据时，我们意识到财会部得到的信息也不全。我们的支付过程控制机制很少。尽管有很多签字——经理们给临时工签上班时间卡，然后临时工把卡交给他们的职业介绍所，介绍所又给我们寄来账单，采购部给这些账单付款——但实际上没有财会控制。一个经理无法确定小时工资率或开了账单的小时总数。一份账单可能会没有签字的时间卡就给我们邮寄来了。一个经理可能会同意给一个临时工涨薪，但临时工雇佣部却可能得不到这个信息。或者一个临时工会在一个项目上得到涨薪，但是这笔涨薪却错记在另一个项目上了。我们没有办法制止开来的双重账单。
　　商务小组退后一点从开头到结尾审视整个过程，并判断数字信息能如何帮助我们管理这个复杂过程。
　　一个管理方面的问题就是，经理是否从一开始就有权雇佣临时工。在我们的书面系统里，没有办法来保证管理人员会审议招聘更多人力资源的最初决定，一旦决定了雇佣一个临时工，经理们没有足够的信息来了解他们是否在遵循相关的业务规则。例如，该经理有干这个工作的预算吗？该经理愿意给这个项目批准加班工资吗？此外，招聘经理无法容易地了解到某项工作合适的小时工资是多少，或哪些有资格的人员能应聘。除非招聘经理心里已经有一个具体的人选，否则我们就没有一种容易的办法来找出一种可能的资源，不管这个资源是一家公司、一个介绍所介绍来的临时工，或是一个独立的承包者。我们为了正确的预算，需要一种自动计算公开招聘全额成本的方法。我们决定我们需要一个新的灵活软件解决方案。对每一个临时工，我们都必须保证他有一份公开写好并签名的合同。合同一旦被批准，那么这个人的卡式钥匙、电话和上网权利必须在48小时内准备好。用户必须能够容易地创造相似职务的多重相同申请，当您准备一个大项目的时候，这是一种典型的局势。当承包者工作时，经理们需要一种简单的方法来确认工作时数、支付工资级别，以及在采购订单上的余额。当合同终止日期临近时，招聘经理需要被自动警告。经理需要能自动地延长该临时工的合同，但条件是预算还有剩余，而且这个人为微软公司工作的日子少于连续的340天。当终止日期到达时，这个人上网、上电子邮件、使用公司电话和房屋的权利就必须停止。
　　我们的新过程必须支持变动，但又不能阻碍工作。当一份合同准备妥当时，假如审批经理不在，那么招聘经理则必须能够把合同转到另一个有审批权的人手里。假如在工作分派期间内经理或成本中心有变动，我们就必须能容易地重新分配该项成本。职业介绍所应能自主给临时工小额加薪，但是大幅度加薪则必须得到招聘经理的同意。
　　决定是否集中管理
　　一种方法就是创建一个巨大的单一应用程序来处理所有这些需求，即所谓的“大程序法”。我们有一次就这样设计过一个应用程序，是用来使我们内部的十几个服务组织——图书馆、保安、饮食、出差、公司仓库、公司信用卡集团和其他组织等——能跟踪雇员请求并做出反应的。最后这个项目是我们所取消的少数项目之一。各个群体的需要是很不相同的，而商务规章又太复杂，一个应用程序处理不了。我们花了那么多的时间来使这个系统运转起来，可等我们完成的时候，需求又改变了。我们接受了一个重要的教训：很少的公司应用程序需要“集中”。我们让每个小组自由建立自己的申请系统。通过缩小解决方案的规模，我们缩减了大量复杂性和开发时间，今天所有的内部服务小组都有自己的“申请”应用程序，他们每隔几个月就改进一次。它们都是无纸过程的极好例子，这些过程节省时间，使得跟踪优质服务的提供更容易。
　　我们避免内部应用程序冗长的开发周期。太多的时间消耗往往使优势失效，而商务需求同时又在发生改变。更小的、非集中的过程通常是最好的。只有少数的应用程序，例如我们的财务报表系统，需要集中化。我们在承担了内部其他商务解决方案的同时，一直保持小规模的小组和项目，心里记着我们生产开发小组的座右铭：“及时交货是我们的特色”。
　　在检查对临时工的管理时，我们想避免一种单一的办法，但与此同时，又不要弄到未了有六七种互不相干的应用程序，不能组合在一起来刨建一个总体解决方案。我们的战略就是，创造一系列模块化应用程序，从开始设计的时候就准备把它们的数字数据互相链接起来。
　　我们主要的工具就是Ms　Market，即我们内联网上的公司采购应用程序；Ms　Invoice，即因特网或称外联网上的一个网址，它使我们的承包商和其他人能用电子方式递送发票；还有我们的SAN系统，它处理所有的后台财务来往。由于我们已经有HeadTrax来管理人事，我们就把它当用户界面来用，不管哪一个应用程序实际上在幕后“拥有密码”。用户只要简单地在HeadTrax上点击某个特征，正确的应用程序就会开启。
　　承包过程从Ms　Market里的数字采购开始，我在第三章中已作过全面描述。创建。雇佣和管理临时工的步骤与HeadTrax为管理正式员工的电子控制功能十分相似。MSInvoice是便利于电子传送发票的，也提供控制功能来帮助招聘经理和销售商（译注：此处指提供临时工的机构）不超过预算。在每一张发票上，招聘经理都有一个链接以查看采购订单上的余额。销售商能看到他们的哪一份账单与哪一份发票匹配。假如一个销售商企图送交一份比采购订单上的余额更大的发票，那么这份发票就会被拒绝。假如销售商给临时工涨薪，微软公司的经理可以点击一个按钮来批准或拒绝。
　　精明的读者也许想知道，我们为什么还要使用发票呢？不管是电子或其他形式的发票？归根结底，制造业大户都能够完全取消发票了。典型的例子就是福特公司取消了存货材料订购发票。当收货部收到了一批零件之后，经手人就在电脑上输入收到这批材料，开始自动给卖方付款。制造商拿到了零件，供应商收到了付款。谁需要一份发票——即使是数字化发票？
　　我们也用一种类似办法做过试验，但是在牵涉到服务而不是实际货物的地方发现了一些差别。在制造业里，每个零件都有一个零件号。要创造与临时工的时间一对一的关系是更困难的。因为您“接收”的是花在一个项目上的小时。没有一个另外的参考，即发票号码，销售商要把一次电子付款与某个工人和某周联系起来是困难的。我们拭目以待，盼望着能为我们的销售商所用的无发票服务付款系统。我们的大问题就是要把临时工过程完全数字化，以便让所有的信息能轻易得到。
　　一条经验法则就是，一个很差的过程会花掉工作本身所需时间的10倍。文献中的许多例子都描述再设计如何把30天的过程减少到3天，或把10天的过程减少到1天。一个好的过程会消除浪费的时间，而技术将会加快剩下的真正工作。但是这种改进并不是最重要的好处。改进管理方对承包过程的监督，保证每个人都遵循招聘指导方针和预算，这些才是大的商务利益。更重要的是，我们能把各行业工种的表现联系起来，而且保持与这些工人更好的关系。
　　一步一步地改进
　　要有所准备，以便试验新过程和技术解决方案。没人能预测一个新过程或新应用程序可能出现的每一个差错或问题。员工们先要使用程序，然后他们和程序开发者才能决定什么真正起作用，什么不起作用。用户一旦亲手用了以后，他们就肯定能看到扩展一个应用程序的新方法。我们直到看到HeadTrax对正式职工起了作用，才意识到我们可以用它来处理临时工的问题。我们直到看到HeadTrax用于人事变动很管用，才意识到我们可以加上跟踪历史信息的功能，以便为预算目的比较逐年的人头变动。这个特征将是下一个版本的一部分。
　　对于所有再设计项目，尤其是那些牵