MENU

KITAHARA COLUMN キタハラコラム

第5回 シェアードサービスセンターキタハラコラム

SSCでの経験

企業グループに属する事業子会社から共通業務をくくりだし、これを集中管理するのがシェアードサービスセンター(SSC)です。対象となるのは、人事、教育、経理、財務、購買、情報システムといった管理部門業務が中心です。中でも給与計算は、必ずSSCの対象に含まれてくる業務です。

SSCの目的は、第一に共通業務の集中管理による効率化であり、第二に業務に関するベストプラクティスの集積です。そしていくつかの企業においては、「将来的には外販をも視野に入れていく」ことを第三の目的としています。コストセンターをプロフィットセンターに変えることができるのであれば、それは経営者にとってなかなか魅力的な話です。

ラクラスの十余名の創業メンバーは、1999年から2005年までの6年間、多くの事業子会社を傘下に収めるソフトバンクグループにおいて、人事と総務のSSCの運営に携わっていました。1999年といえば、商法が改正され、純粋持株会社と事業子会社という組み合わせが認められた年です。SSCに関する議論は、この組み合わせが認められたことに伴って活発化してきました。ソフトバンクグループは、SSCの設立においても先駆者でした。

今回は、私達の6年間の経験から導き出された、SSC成功に向けてのポイントについてお話いたします。私たちの人事・総務SSCは財務的には成功と呼んでよいレベルにまで成長しました。しかしその一方で、SSCの抱える根源的な問題を解決するまでには至りませんでした。

財務的成功のポイントとは何なのか。SSCの根源的な問題とは何なのか。そこから再定義されるSSCの役割は何なのか。6年間の経験を通じての発見は、既にSSCを設立している企業にも、現在SSCを検討している企業にも、お役立ていただけると思います。

業務の集約による規模の経済

SSC設立の第一の目的は、「共通業務を集約することにより“規模の経済”を追求し、業務処理にかかる平均コストを削減すること」です。“規模の経済”とは、処理すべき業務量が増加するに従って、処理に必要な経営資源の増分が減少していく状態を指します。

企業グループ内のある子会社が、給与計算システムを導入するのに1単位の経営資源を必要とすると仮定します。子会社10社がそれぞれ別個に給与計算システムを導入したとすれば10単位の経営資源が必要となり、100社がそれぞれに導入すれば100単位が必要となります。

給与計算システムをSSCに集約すれば、1社目の導入には1単位の経営資源が必要になります。しかし社数が増えるにつれて、必要とされる経営資源の増分は1単位より少なくなっていくはずです。その理由の一つは、給与計算システムを稼動させるための固定費用を多くの企業に分散できるためです。あるいは、導入の手順に関するベストナレッジが蓄積されることで、導入期間が短縮され、より少ない経営資源で導入できるようになるためです。

つまり、「多くの子会社の給与計算業務を、SSCの一つの仕組みに集約できるのであれば、規模の経済が効果を発揮し、より少ない経営資源でより多くの業務を処理できるようになる」はずです。しかも、「規模が大きくなればなるほど、必要な経営資源の増分はより多く減少する」はずです。経営者の目論見は、まさにこのポイントにあります。

しかし、これまで私達が研究した多くのケースにおいて、この目論見の通りにSSCの事業が進展することはありませんでした。何故でしょう。

業務を集約するだけでは、規模の経済は機能しない

規模の経済を機能させるポイントは、「一つの仕組みに集約できるかどうか」にあります。一つの仕組みでより多くの業務を処理するからこそ、処理にかかる平均コストを減少させることができます。しかし私達の知る限り、一つの仕組みですべての子会社の処理を行う技術をもったSSCは皆無です。

現実のSSCは、多くの場合、社数の増加に対して、複数の仕組みを導入することで対応しようとしています。親会社のために大規模な人事・給与パッケージソフトを導入し、それぞれの事業子会社のために小規模なパッケージソフトを個別に導入するといった対策が、このケースに当たります。

いずれは子会社の処理にも使おうという目論見をもって大規模パッケージを導入したはずなのに、親会社が使いやすいように徹底したカスタマイズを行った頃には、とても子会社には展開できないぐらい柔軟性のない仕組みになってしまった、という話もよく聞くところです。

この方法では、規模の経済は機能しません。SSCに複数の仕組みを導入するということは、パッケージソフト、ハードウェア、OS、あるいはこれを動かすエンジニア等の経営資源を、子会社に成り代わってSSCが保有している状況に過ぎません。所有者が代わっただけで、ソフトウェアの本数もサーバの台数も減少していません。

一箇所で保有することにより、ベストナレッジは蓄積されるかもしれません。しかし規模の経済が働くことはほとんど期待できません。つまり、複数の仕組みを導入している限り、「業務集約による経営資源の削減」という当初目標は成し遂げられないのです。

企業ごとに異なるビジネスルールを、一つの情報システムの上で実現する仕組みを、「マルチテナント」と呼びます。1999年以来、人事情報処理の分野において、私達はマルチテナントの仕組みを作り上げてきました。マルチテナントこそが業務を徹底的に効率化し、SSCを財務上の成功に導くための基礎になります。

外部のアウトソーサとの競争

マルチテナントを実現して、規模の経済を手に入れたとしても、SSCには次の壁が立ちはだかります。それは外部のアウトソーサとの競争です。

規模の経済が競争力のすべてであれば、SSCがアウトソーサに勝つ術はありません。なぜなら、処理量の最大値がグループ企業の従業員総数に限られているSSCに対して、アウトソーサの最大値は全企業の従業員総数だからです。

しかもSSCは、「グループ内の業務委託を断ることはできない」というハンディキャップを背負っています。アウトソーサであれば、自社の事業戦略に従って商談を選ぶことができます。規模の経済を獲得するために、社員数の少ない企業よりも多い企業を選ぶのは、アウトソーサにとって当然の行為です。

しかしSSCは、グループ会社であればどんなに小さい会社でも、その仕事を断るということができません。しかも最近はM&Aなどで、歴史も人事規程もまったく異なる会社がグループに入ってくることがあります。引き受けたくない会社も引き受けなくてはならないというのは、大変なハンディキャップです。

一方で、通常の企業グループでは、事業子会社たちはグループ内のSSCに業務を委託することが義務付けられます。SSCにとっては一定の顧客数は確保されることになりますが、逆の立場で見ると、「事業子会社は自分たちの要求するサービスを提供するアウトソーサを自由に選べない」ということになります。

ソフトバンクは大変厳しい会社で(とても鍛えられました)、グループ内各社は、私達の人事・総務SSCに業務を委託する義務に縛られていませんでした。SSC設立当時に私達は、外部のアウトソーサに負けない料金とサービスレベルを作り上げるよう言い渡されました。グループ内各社には、外部のアウトソーサに業務委託する自由が与えられました。

私達はマルチテナントを確立していました。規模の経済を獲得するだけの準備は整っていました。しかしグループ内が相手というだけでは、そもそも外部のアウトソーサに対抗できるだけの規模をもつことはできません。値段だけで競争していたら、グループ内各社は外部のアウトソーサを選んでしまいます。差別化するためには、サービスレベルを変えるしかありません。

「アウトソーサができないサービスは何なのか?」を考え抜いた結果として導き出されたのが、「トランザクション処理も請け負う」という発想でした。

トランザクション処理も請け負う

定められた形式に取り揃えられた大量の入力データを一括して処理する方法を「バッチ処理」と呼びます。

給与計算はその典型です。すべての入力データを定められた形式に取り揃えれば、あとはコンピュータが計算してくれます。逆に言うと、給与計算に必要なすべての入力データを定められた形式に揃えておかない限り、バッチ処理は開始できません。ある一人の社員のある一日の出勤時刻が打刻されていないだけで、その月の給与計算処理は開始できないのです。

バッチ処理に必要な一つひとつのデータを収集し、定められた形式に整える作業を「トランザクション処理」と呼びます。トランザクション処理の範囲は幅広く、バラエティに富んでいます。

たとえば、出勤時刻と退勤時刻はタイムカードで収集され、月次単位で集計されます。個人の身上変更は、家族異動届や住所変更届により申請されます。昇給額や賞与額は企業の側が決定します。いずれも定められた経路に従って承認されなければなりません。これらはすべてトランザクション処理です。

これまでのアウトソーサは、トランザクション処理をサービスとして提供してきませんでした。トランザクション処理はクライアントである企業の側の責任範囲です。給与計算アウトソーサの主たるサービスは、給与計算のバッチ処理を行うことだけです。

トランザクション処理を提供している若干のアウトソーサも、複数のテンプレート(雛形)を用意しているだけです。しかしながら、テンプレートだけでバラエティに富んだトランザクション処理を代行することは困難です。たとえテンプレートで8割のケースをカバーできるとしても、残る2割の申請書類は紙のまま残ってしまいます。申請書の種類によって申請方法が違うようでは、効率化は望めません。社員は混乱し、問い合わせの電話が増えるだけです。

私たちはSSCをアウトソーサから差別化するために、トランザクション処理をサービスとして提供することにしました。しかし、トランザクション処理を手作業で行っていては、規模の経済を得ることはできません。処理量の増加に正比例して必要な経営資源、すなわち社員の数が増えるだけです。

そこで私達は、企業ごとに異なる仕様に柔軟に対応できるワークフローソフトウェアを開発することにしました。私たちはこのワークフローソフトウェアにおいても、マルチテナントを実現することに成功しました。

ワークフローソフトウェアにより、SSCの業務効率は圧倒的に改善されました。年末調整業務を手作業からこのソフトウェアの活用に切り替えた2002年、年末調整関係書類を配布し督促し回収する作業の効率は80%改善されました。言い換えれば、作業時間が5分の1に縮小されたのです。

書類さえ集めることができれば、バッチ処理に要する時間にさしたる差はありませんでした。トランザクション処理にこれまで割いていた時間の膨大さに、私たちは唖然としたものです。

現在、このワークフローソフトウェアは「LIP : Lacras Interactive Platform」と名づけられ、ラクラスのすべてのお客様において、就業管理、身上申請、年末調整、経費精算、あるいは人事評価や自己申告など、幅広い業務に活用いただいています。

SSCの根源的な課題

トランザクション処理をサービスとして提供したことは、SSCを外部のアウトソーサから差別化する戦略として有効に機能しました。またバッチ処理とトランザクション処理の双方においてマルチテナントを実現したことは、私たちに規模の経済をもたらし、それは業務効率の圧倒的な効率化に貢献しました。これらはSSCの財務的成功の基礎になる技術でした。

しかし私たちのSSCは、財務的成功は収めたものの、SSCのもつ根源的な課題を解決することはできませんでした。それは、「SSC社員のモチベーション」という課題です。

SSCが対象とする顧客は、グループ内企業であることが基本です。つまりグループ企業全体を顧客としてしまえば、そこが売上の増加の上限です。グループ全体の社員数が増加したり、サービスメニューを継続的に拡大したりしない限り、SSCに成長の余地はありません。

売上が増えないということは、社員の昇給原資も手に入らないということです。昇給原資を手に入れるためには、業務を効率化して費用を削減し利益を生み出すか、あるいはグループ外に新たな収入源を求めるか、いずれかの方法しかありません。

しかし、業務効率化だけで利益を増加させ続けることはできません。たとえば、ミスによる手戻りを減少させるのは業務を効率化するための有効な方法ですが、ミスをゼロ以下にすることはできません。限界まで突き詰めたとしたら、あとは人件費を下げる以外に手がなくなってしまうのです。

売上を増加させないまま、費用削減だけで利益を稼ぎ続けることはできません。より良い未来が期待できなければ、社員のモチベーションは下がるだけです。

グループ外への展開は図れるのか

このような事態を避けるために、多くのSSCは設立にあたって、「将来的には外販をも視野に入れていく」という第三の事業目的を付け加えます。そしてグループ外でのビジネスチャンスを求めることを試みます。

しかし私達の知る限り、グループ外への展開に成功した例はほとんどありません。その背景には、次のような理由があるように思われます。

第一に、SSCに集約されたベストプラクティスは、その企業グループのベストプラクティスであり、グループ外には通用しないという現実です。

アウトソーサとして多くの企業とお付き合いするほどに私の確信は深まるのですが、人事制度は、経営者の思い入れや歴史によって、企業ごとに大きく異なります。そのバラエティの豊かさは、常に想像を上回ります。このバラエティを吸収できるだけの柔軟性をもった仕組みを、マルチテナントで構築できることがグループ外へ展開するための第一条件ですが、それは容易なことではありません。

グループ外への展開を困難にする第二の理由は、上に述べたような仕組みを構築しようにも、SSCには十分な資金がないことです。新たなビジネスを立ち上げるのであれば、どのような場合においても、相応の資金の投下が必要です。しかし、コストセンターとして出発したSSCには、その資金がありません。

そもそもSSCの業務内容は、グループの共通業務をくくり出したものであって、グループの本業ではありません。本業ではない事業に資金を投下するという決断を経営者が下すことは、現実にはまずあり得ないのではないでしょうか。

そして第三の理由は、グループ外に展開しようにも、SSCにとってはグループ内の仕事がまず優先するということです。日々発生する社内からの様々なリクエストに応えるだけで、SSCはもう手一杯です。グループ外までとても手がまわりません。

コストセンターであるSSCは、グループ外に展開するだけの人的資源をそもそも持っていません。たとえ人的資源に余裕があったとしても、これまで給与計算業務を社内で担当してきた人材が、グループ外の企業への営業で成功するとも思えません。

このように考えると、いくらグループ内のベストプラクティスを集約したところで、外販につながる道があるようには私には思えません。かくいう私達も、一時期はソフトバンクグループ内での成長を目指したものの、結局はスピンアウトして、ラクラスを設立することになるのですが…。

SSCの役割を再定義する

ここまでの議論をまとめてみましょう。

グループ内という限定された市場で、しかも顧客を選択する自由を与えられないという条件のもとで、利益を最大化せよという指示を与えることは、もとより矛盾を抱えているということは明らかです。自らマーケットを選ぶこと、自ら顧客を選ぶことは、事業を成立させるための最低条件です。この条件を認めずにプロフィットセンターであることを求めることは、両手両足を縛り上げながら自力で泳ぐことを求めているようなものです。

ではその制限を取り払い、グループ外に事業展開できるのかというと、これも答えは否です。そのために必要な資金、人材、システムインフラといった経営資源を、SSCはもっていません。本気で外販するのであれば、既にマーケットで活動しているアウトソーサに対して競争優位を確立できるだけの事業計画を策定し、しかるべき資金を投入することが不可欠です。しかし、非本業業務に資金を投じるというリスクを、いったいどれだけの経営者が受け入れることができるでしょうか。

コストセンターをプロフィットセンターへの変えるのは、容易なことではないのです。

私は、「グループ内の共通業務を集約した、極めて効率の高いコストセンター」を目指すことが、SSCの第一の役割だと思います。プロフィットセンターであることを目指すのは、まずこの第一の役割を十分にこなすことができてからでしょう。

高効率性達成へのキーワードは、トランザクション処理とマルチテナントです。Webベースの多企業間ワークフローソフトウェアは、グループ企業間を流れる変動情報を一括して管理することを可能にします。ラクラスのワークフローを利用した場合、年末調整、タイムカード、給与明細のような配布・督促・回収作業の工数は、5分の1にまで削減されることが実証されています。

またSSCは、全グループ企業の人事情報を一元的に管理する人事データベースを作り上げる役割を担うことができます。マルチテナントに対応した人事データベースは、アクセス権限を詳細に設定することができます。本社人事部は全グループ企業の人事情報を参照し、各グループ企業の人事部は自社の人事情報を参照し、SSCは全グループ企業の給与関連の情報を加工するといった設定が可能です。

ワークフローとデータベースにより情報武装されたSSCは、本社機構の一部として、最新の人事情報を経営者に提供できる存在へと変わるでしょう。給与計算のバッチ処理だけにはまり込むことなく、最も希少な経営資源である「人材」に関する情報を統合して管理する役割を、SSCは果たすことができると思います。

本社機構の一部という役割はまた、SSC社員のモチベーションという課題の解決にも役立ちます。企業はいま、法令順守あるいは内部統制に関して多くの責任を負っています。その範囲は親会社だけではなく、連結決算に影響を与えるすべての子会社に及びます。

承認経路をSSCのワークフローに統合すれば、人事上の申請や承認に関して確実な記録を残すことができます。タイムカードを電子化すれば、その日までの総労働時間数や36協定の上限までの時間数を表示することができ、職場での自主管理に役立ちます。

またデータベースが一元化されていれば、人材の有効利用も可能になります。新規事業を開始するとき、グループ企業全社から候補者を選ぶことができるようになります。ある子会社でリストラを行っている一方で、別の子会社では採用を増やしているといった無駄を省くことができるようになります。

今後ますます重要になる「グループ統治」の役割の一部を担わせることは、SSC社員のモチベーションの観点からも有効な解決策になるでしょう。

ラクラスは、SSCの情報武装のお手伝いをいたします。ラクラスが作り上げてきたマルチテナントのワークフロー、人事データベース、および給与計算システムは、規程や制度の異なるグループ企業各社を、一つのシステム上に統合することができます。

自社でゼロからパッケージソフトウェアを構築する必要はありません。SSCの運用経験と、数多くの情報システムの構築経験をもつラクラスにお声がけください。