第30部分 (第1/4頁)

丟丟提示您：看後求收藏（筆趣閣小說www.biqugexsw.tw），接著再看更方便。

沒有足夠的資訊來了解他們是否在遵循相關的業務規則。例如，該經理有幹這個工作的預算嗎？該經理願意給這個專案批准加班工資嗎？此外，招聘經理無法容易地瞭解到某項工作合適的小時工資是多少，或哪些有資格的人員能應聘。除非招聘經理心裡已經有一個具體的人選，否則我們就沒有一種容易的辦法來找出一種可能的資源，不管這個資源是一家公司、一個介紹所介紹來的臨時工，或是一個獨立的承包者。我們為了正確的預算，需要一種自動計算公開招聘全額成本的方法。我們決定我們需要一個新的靈活軟體解決方案。對每一個臨時工，我們都必須保證他有一份公開寫好並簽名的合同。合同一旦被批准，那麼這個人的卡式鑰匙、電話和上網權利必須在48小時內準備好。使用者必須能夠容易地創造相似職務的多重相同申請，當您準備一個大專案的時候，這是一種典型的局勢。當承包者工作時，經理們需要一種簡單的方法來確認工作時數、支付工資級別，以及在採購訂單上的餘額。當合同終止日期臨近時，招聘經理需要被自動警告。經理需要能自動地延長該臨時工的合同，但條件是預算還有剩餘，而且這個人為微軟公司工作的日子少於連續的340天。當終止日期到達時，這個人上網、上電子郵件、使用公司電話和房屋的權利就必須停止。

我們的新過程必須支援變動，但又不能阻礙工作。當一份合同準備妥當時，假如審批經理不在，那麼招聘經理則必須能夠把合同轉到另一個有審批權的人手裡。假如在工作分派期間內經理或成本中心有變動，我們就必須能容易地重新分配該項成本。職業介紹所應能自主給臨時工小額加薪，但是大幅度加薪則必須得到招聘經理的同意。

決定是否集中管理

一種方法就是建立一個巨大的單一應用程式來處理所有這些需求，即所謂的“大程式法”。我們有一次就這樣設計過一個應用程式，是用來使我們內部的十幾個服務組織——圖書館、保安、飲食、出差、公司倉庫、公司信用卡集團和其他組織等——能跟蹤僱員請求並做出反應的。最後這個專案是我們所取消的少數專案之一。各個群體的需要是很不相同的，而商務規章又太複雜，一個應用程式處理不了。我們花了那麼多的時間來使這個系統運轉起來，可等我們完成的時候，需求又改變了。我們接受了一個重要的教訓：很少的公司應用程式需要“集中”。我們讓每個小組自由建立自己的申請系統。透過縮小解決方案的規模，我們縮減了大量複雜性和開發時間，今天所有的內部服務小組都有自己的“申請”應用程式，他們每隔幾個月就改進一次。它們都是無紙過程的極好例子，這些過程節省時間，使得跟蹤優質服務的提供更容易。

我們避免內部應用程式冗長的開發週期。太多的時間消耗往往使優勢失效，而商務需求同時又在發生改變。更小的、非集中的過程通常是最好的。只有少數的應用程式，例如我們的財務報表系統，需要集中化。我們在承擔了內部其他商務解決方案的同時，一直保持小規模的小組和專案，心裡記著我們生產開發小組的座右銘：“及時交貨是我們的特色”。

在檢查對臨時工的管理時，我們想避免一種單一的辦法，但與此同時，又不要弄到未了有六七種互不相干的應用程式，不能組合在一起來刨建一個總體解決方案。我們的戰略就是，創造一系列模組化應用程式，從開始設計的時候就準備把它們的數字資料互相連結起來。

我們主要的工具就是Ms　Market，即我們內聯網上的公司採購應用程式；Ms　Invoice，即因特網或稱外聯網上的一個網址，它使我們的承包商和其他人能用電子方式遞送發票；還有我們的SAN系統，它處理所有的後臺財務來往。由於我們已經有HeadTrax來管理人事，我們就把它當使用者介面來用，不管哪一個應用程式實際上在幕後“擁有密碼”。使用者只要簡單地在HeadTrax上點選某個特徵，正確的應用程式就會開啟。

承包過程從Ms　Market裡的數字採購開始，我在第三章中已作過全面描述。建立。僱傭和管理臨時工的步驟與HeadTrax為管理正式員工的電子控制功能十分相似。MSInvoice是便利於電子傳送發票的，也提供控制功能來幫助招聘經理和銷售商（譯註：此處指提供臨時工的機構）不超過預算。在每一張發票上，招聘經理都有一個連結以檢視採購訂單上的餘額。銷售商能看到他們的哪一份賬單與哪一份發票匹配。假如一個銷售商企圖送交一份比採購訂單上的餘額更大的發票，那麼這份發票就會被

《未來時速什麼時候出版的》 第30部分（第1/4頁），本章未完，點選下一頁繼續閱讀。