前回に引き続いてシステム化企画書に着手する前に検討すべき点を考えて行きたいと思います。
繰り返しになりますが・・・
図１
企業活動は、大きく眺めると図１のように５つのパーツから成り立っています。
1. 諸規定・制度
2. 組織・分掌
3. 業務プロセス・業務ルール
4. 人材・スキル
5. ＩＴシステム
企業がシステムを開発しようとしていると言うことは、何かの環境変化が起きていると言うことになります。環境変化に直面した場合、企業の採るべき態度は、この５つのパーツそれぞれについて「採用すべき変化・革新」を検討し１～４だけではその変化に対応できないと分かってはじめて５．ＩＴシステムに手をつけるのです。（現代では、殆どのケースで何らかのＩＴが必要ではあると思いますが。）
今回は前回に続いて、３．業務プロセス・業務ルールから考えたいと思います。
３．業務プロセス・業務ルール
以前のブログ「業務プロセス（ビジネスプロセス）って何だろう？A005 2022年3月15日」で、ビジネスプロセスについて解説を行いましたので、今回はビジネスプロセスがどういうものであるかは繰り返しません。
まず、業務プロセス（ビジネスプロセス）ですが、筆者が大規模開発を経験した30数年前から、日本でもシステム化が進みました。それが意味するところは、それまで手で処理していた多くのプロセスがソフトウェア化され、システム内に保存されたと言うことです。その結果がもたらしたものは、人は、手で仕事をしていた時のように手順やルールの多くを考えることがなくなり、システムの操作（オペレーション）さえ出来れば仕事が済んでしまうという事態でした。本来の業務プロセス全体を理解している人の数が大幅に減ってしまったのです。
このことは、同時にベテランを中心とした業務の「属人化」も引き起こしました。業務が「分かっている人」に任せきりとなり、組織全体から見ると不都合なことがいろいろと発生するようになったのです。その例を挙げると以下にような「お困りごと」が起きます。
l 特定の人に特定の業務が集中する。
l その人が行っている業務がブラックボックスになり、他の人には分からない。
l その人がいないと業務が滞る。
l 人によって業務の品質にバラツキがでる。
l 他の人（特に若手）に技術の移転が出来ない。
l 例えば、コスト計算等も、その人任せになってしまい、ルールが形骸化する。
ビジネスアナリシスで、この問題を解決した事例を以下に示します。
ある板金工場で、見積もりをベテランの職人さん任せにしていましたが、ビジネスアナリシスによりベテラン職人さんの暗黙知であった見積りを分析し、営業部・設計部・購買部・製造部に業務を構造化・形式知化した例を以下に示します。
ベテランの職人さんに「見積り」のやり方を尋ねると「一口に見積りって言ってるんですけどね。」と言語表現にすることが苦手なことが多いです。
そこで、見積り業務構造化のための調査項目を設定しキメ細かく分解します。
- 設計補助
- 工法検討
- 材料取り
- コスト積算
- 売価決定
図２
そのヒアリングの結果が図３です。ベテランの職人さんは営業部・設計部・購買部・製造部の間を調整して見積りを行っていることが分かりました。その結果をモデル化したものが図３です。
図３
この工場ではそれまで職人さんの経験に頼っていた見積りプロセスをモデル化し関係部門役割と責任を明確にするとともに、それまで曖昧だった「コスト計算・売値決定ルール」も業務ルールとして制定しました。
このように、業務プロセス検討では「属人化」され特定の人間の「暗黙知」に頼っている業務がないかを検討することをはじめとして、その他の業務も業務手順書、業務フロー図などで制定されているか、また、その内容は適切か・・・と言うことを調査することが重要です。
また、同様に重要な検討事項があります。それは「サイロ化」の問題です。以下にその例を示します。（Fundamentals of Process Management : by Robert M. Curtice より翻訳）
図４
一般的な、商品の販売工程を図４に示しました。しかし、各業務は1部門で処理されるわけではなく図５のようにいくつかの部門のそれぞれが分担して処理が行われています。
ここで、課題になるのは本来一連の業務として処理されるべき販売工程が複数の部門（機能）に分割されると言うことです。
図５
一般の企業活動では、各部門は「各部門の業績責任」に従って行動していて、一連の流れであるべき（この場合）「販売活動」全体については責任を負っていないと言うことを理解する必要があります。各部門は自部門における業務の「最適化」を図るべく努力しますが、この例における「商品販売工程全体」に対しては、責任を担っていません。これを「サイロ化」と呼びます。このケースのように単純な事例であれば、おそらく問題にならないでしょうが、もっと複雑なケースでは部門間の利害が対立してコンフリクトを起こしている場合も考えられます。そのような場合には組織運営上大きな問題となるでしょう。
従って、業務プロセスを調査する場合には、部門（機能）ごとに調査するのではなく、業務プロセス全体を「エンドツーエンド（End-To-End）」で調査する必要があります。
これは、前回採り上げた「組織・分掌」とも関連する非常に重要な要素ですので、是非、押さえておいてください。
業務プロセス分析は組織構造とプロセス階層レベルを意識しつつ、上位の経営要求から下位の要求に構造化しつつ分析します。業務プロセスが各階層の要求を満たしていない場合には業務プロセスの改変を検討しあるべき姿の業務プロセス（ToBe）を設計します。その際に業務プロセスの変更にＩＴシステムの変更が必要か、現行のシステム機能では足りない部分が生じるかを検証します。
次に「業務ルール」ですが、図６の通り業務プロセスと業務ルールは一体のもので、業務プロセスは業務ルールが定めるところに従って運営されます。
図６
業務ルールは、多くは「業務手順書」や「マニュアル」にまとめられていると思われますが、同時に個人の経験や知識に依存していて文書化されていないケースや、文書化されていてもアップデートされていないケースも多くみられます。従って、業務プロセスを調査する場合には、各個別プロセスに対応した「正しい」業務ルールがしっかりと「文書化」され且つ「最新版」であり、組織全体として認知されていることを確認することが重要です。
４．人材・スキル
つぎは「人材・スキル」です。業務プロセスにおいてエンドツーエンドでの把握が重要だと申しましたが、その上で、その業務プロセスを運用するために「必要な人材が配置されているか？」「その人材のスキルはプロセスを運用する上で十分に高いか？」を検証する必要があります。
よく見られる現象では、ここでも「属人化」が問題となりますが・・・「ベテラン任せになっていないか？」「若手の技量教育は上手く進んでいるか？」など、人材・スキルが業務プロセス上のボトルネックになっていないかを確認します。
５．ＩＴシステム
上で述べたように、ＩＴシステムはあるべき姿（ToBe）の業務プロセスに十分な機能を提供しているか・・・と言う観点で検証します。
この時、留意すべきは、ＩＴシステムは必ず使われるものでなければなりません。別の言い方をすると、導入したＩＴシステムを使わないと業務が回らないように設計する必要があり、使われないＩＴシステムを作ってはいけないと言うことです。
よく例に出されるのは、「CRM(Customer Relationship Management)システムを導入したが営業の担当者が入力をしてくれないので上手く活用できずにいる。」といった類の話しです。ＣＲＭ自体は優れたシステムであっても使われなければ無駄な投資になってしまいます。ＣＲＭを導入するにあたっては、担当者の入力負担や、管理者の管理負担も発生します。そんな中で、負担を強いられる担当者や管理者にメリットが感じられる業務プロセスを構築することが必須条件になりますし、組織・分掌、報告制度なども含めた制度設計が必要になるでしょう。システムの機能だけに目を奪われてしまうとこういう事態も起きかねません。特に情報系システムではシステムへのインプットが確実に行われ、アウトプットが確実に経営判断をはじめとする各種の判断業務に活用されることへの注意が必要です。