システムに業務を合わせるべき(1)-部分最適と全社最適

2018年9月13日木曜日

システム開発

t f B! P L

 最近、日本の情報システム開発の問題を指摘する声が高まっている。
その中に「日本では業務にシステムを合わせて作るが、欧米や中国ではシステムに業務を合わせる」というものがある。
 「何でも欧米に合わせる必要は無い」という愛国者の方もいるだろうが「日本のホワイトカラーの生産性は低い」という有名なデータもある。


で書いたが、
スクラッチによるシステム開発も、パッケージのカスタマイズも大変難しく、非常にコストがかかる。
日本ではシステムやソフトウェアのような「目に見えない」ものの価値を評価しない・出来ない、ので業務システムの開発も簡単に考えているところがあり、「どうしてたかがシステムなんかに人間様(オレ様)が業務を合わせなければならないのだ。ケシカラン!」と頑なに業務にシステムを合わせさせる。
日本のホワイトカラーの生産性は世界的に見ても高くはないと言われており、その生産性の低い業務に合わせてシステムを開発し生産性が向上するかと問われれば、私なら「否」と答える。「そんなわけ無いだろ! どう考えたら生産性が上がると思えるんだよ」と答える。

私は「システムに業務を合わせる」考え方が正しいと思うし、これはITエンジニアなら常識だろう。

今回は「何故、システムに業務を合わせる必要があるのか」という点で私の認識を説明する。

業務用パッケージソフト

通常はバックオフィス業務や顧客管理業務、会計業務、在庫管理業務などは「周辺業務」であり会社の利益を主導する「中核業務」ではない。
当然、周辺業務に対して積極的に投資するわけもなく、正常な企業なら余剰利益は中核業務に優先投資するだろう。
すると周辺業務は常に「三流」の状態を維持することになる。少なくとも「一流」の水準ではないと思う。もし「一流」ならばそちらも本業にした方が良いし「今まで本業はどうしていたのだ」と株主に突っ込まれるかも知れない。どちらにせよ周辺業務に積極投資は出来ないし中核を放置して周辺に積極投資するのも不自然だ。

会社にもよるがこれまでの日本企業は周辺業務も自社の業務に合わせてシステムを外注開発してきた。その周辺業務は説明したように「一流」であるはずがないのだ。むしろ「一流」では投資配分で問題なのだ。

「周辺業務」ではその業務を専門とする会社の業務手順を導入すべきだし、その会社が開発し運用している業務パッケージを導入した方が、優れた業務を導入し生産性を向上させることが出来るだろう。

「中核業務」については自社の業務が一番優れている(べき)なので自社でシステム開発すべきだろう。

ERP の SAP や CRM の Salesforce, OBC の 奉行, 富士通 GLOVIA など業務パッケージソフトベンターは、それぞれの業務の専門家である。
しかもユーザーからのフィードバックを常に受けており、その結果を次期バージョンに反映し常に進化を続けている。

日本企業はこのパッケージソフトを、さほど進化しているとも一流とも言えない自社の「周辺業務」に合わせてカスタマイズして使用する。
パッケージは次々アップグレードしてゆくのに古いバージョンを使い続ける。
日々進化を続けるパッケージベンダーの優れた業務手順を導入することなく、わざわざ機能を劣化させて古いパッケージソフトを使用しているのである。
馬鹿馬鹿しいと思わないだろうか ?

企業には「中核業務」と「周辺業務」があり投資効率と投資の優先順位から利益は中核業務へ優先的に投資しなければならない。
従って周辺業務は他社と比べて優れたモノにはならず、その周辺業務を専業とする他社の業務パッケージをそのまま導入した方が、優れた業務を導入できるのだ。

故に業務パッケージの業務手順は、元のその会社の周辺業務より優れており、業務は業務パッケージの業務手順に合わせた方が、優れた業務を導入できるのだ。
従って「システム(業務パッケージソフト)に業務を合わせる」べきなのだ。

部分最適を全社最適へ

部分最適の一例

日本の企業人は日々目前の業務改善努力を繰り返している。
しかし、コミュニケーションのやり易さからその改善は部署や課などのセクションの中に閉じたものに成り易い。
しかし各セクションに閉じた効率化は必ずしも会社全体の効率化にはならない場合がある。
製造業の原材料の仕入れに例えてみよう。
セクションAが製造する複数の原材料の調達コスト削減のため取引先Mから一括仕入れで価格を引き下げていたとする。
セクションAだけなら効率的だが、その原材料の一部は他のセクションでも使用しており、会社全体ではセクションごとにバラバラに同じ原材料を調達しており非効率になっている。

全社最適の一例

ある程度大きな会社であれば良くある話だ。
こういう時は規模の経済が働くので、会社全体で共通する原材料を一括調達した方が安い単価で仕入れができる。
その代わりセクションAは取引先Mとの一括取引が出来なくなり他の原材料を安く調達出来なくなる。

企業の合成の誤謬

経済に「合成の誤謬」という言葉がある。

企業や家計など国民の全てが堅実に貯蓄に励んだとする。
誰もが「借りた金」より「貸した金」の方が多い状態を目指し、「消費」を減らし「貯蓄」を増やしたとする。
すると金を借りる者が居なくなり、金を貸す相手が居なくなるので「借りた金」より「貸した金」の方が多くなることは永遠にない。
また、「消費」を減らした分「所得」が減るので「貯蓄」金額を増やせなくなる。

個々人が「正しい行為」を行っていても、国全体では「間違った行為」になる事がある。
これを「合成の誤謬」と言う。

企業においても同じ事が起きる。
先の例がそれだ。
各セクション(部・課)はそれぞれ効率化と最適化の為最善を尽くしているのに、会社全体では非効率になる。
部分最適が全体最適を阻害することがある。
この場合は「部分最適を放棄してでも全体最適を実施する」必要がある。

現場レベルでの改善努力に任せきりでリーダーが適切な「全社の最適化」を怠っていると「合成の誤謬」状態により全社の生産性が悪化する。

標準化・重複排除・単純化・大規模化そして自動化

全社の最適化の基本的パターンは「業務手順の標準化」「業務の部署ごとの重複の排除」「業務手順の単純化」「業務手順の大規模化」といったところだと思う。

「業務手順の標準化」とは同じような業務を遂行するのに各セクションや個人ごとにバラバラの手順で実施していて不効率な場合、全社で業務手順を統一することで効率化することである。

「業務の部署ごとの重複の排除」は言葉の通り、全社で統一された業務手順の中でセクションごとに同じ作業を専任担当に一任したりすることだ。

「業務手順の単純化」も言葉の通り、業務手順の工程を簡略化して効率化することだ。

「業務手順の大規模化」はバラバラにやっていた業務を一カ所で行うことにより規模の経済で効率化することだ。専業の業者に外注することも含む。

そしてこれらの最適化を全て行えば「業務手順の明確化」が達成されるので「自動化」又は「半自動化」ができるようになる。

システムは業務手順を規格化し強制できる

仮に「業務手順の標準化」を行ったとしても従業員が従わなければ「絵に描いた餅」となる。
システムの導入は従業員にシステムの使い方を規定し指定の業務手順を強制することが出来るメリットがある。
仮に従業員が指定の手順に従わなくてもシステムのUIの通りに操作しないと「システムは動かない」ので嫌でも従わなければならない。
これはシステムの良いところでもあり怖いところでもある。

部分最適は現場の従業員にとっても納得できる内容なので素直に従うと思うが、全社最適だと納得できずに従わない可能性がある。
システムはこれを強制できる。

全社最適にはシステムが必要

全社最適には「業務手順の標準化」が必要であり、規格化した手順に現場を従わせる必要がある。
システムはそれを実現できる。
そしてその状態は「システムに業務を合わせる」ことを意味する。

「全社最適」=「業務手順の標準化」=「システムに業務を合わせる」

ということだ。

以上が一つ目の「システムに業務を合わせる」理由である。

次回は二つ目の理由を説明する。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ