情報システムをデザインするということ
少し前になりますが、こういう記事がありました。
日本生命が営業支援システムをSaaSへ移行、「オンプレミスでは手間がかかり過ぎた」
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/031700199/ - ITPro
要約すると
- 記事の企業が、営業支援システムを「従来のやり方」から、クラウドへ移行した。
- 「従来のやり方」は手間のかかるものであった。
- やり方を変えたことで、業務のスピードが上がった。
というものです。
この記事を読んで思ったのが、実感として「2」で止まっている組織はまだまだ多いよね、でも、いろいろ難しいよね、事例の会社はどうやって進めていったのかな？、ということでした。
記事の企業では、
- 営業関係のデータベースは、社内のファイルサーバに保管している。
- セキュリテイの関係上、地方の出先などは直接ファイルサーバにアクセスできない。
- そのため、本社担当者はデータをエクセルに抽出し、地方担当者等にメール送付し、
- 地方担当者は、本社から送られてきたエクセルを更新し送り返す。
- 本社担当者は、各者から収集したエクセルファイルをファイルサーバのデータベースに反映する。
というプロセスを踏んでいるようでした。
図示すると以下のような形になります。データ件数や頻度は記事からは分かりませんが、とても手間がかかります。手間がかかる上に、転記ミスなどエラーも無視できません。
<図-1>
上記のような図を「物理モデル」と言います（ザックリですが）。実際に関わる人やプロセスを記載するというやり方です。
一方、対義語的に「論理モデル」という言葉もあり、こちらは、ネットワーク構成や中継者等を無視し、正味のデータの流れを表現するというやり方なのですが、この件を論理モデル的に表すと以下のようになります。
<図-2>
とてもシンプルです。今回の事例は、クラウドサービスを導入して「論理モデルに近い物理モデル」を構築したという話になります。
いったい何が難しいのか？
話だけ聞くと、「論理モデルに近い物理モデル」を構築するのはあまり難しいことではなないように思えます。しかし、「手間のかかるやり方」のままの組織は多くあります。
では、このように「やり方を変える」ことの何が難しいのでしょうか？
その辺りについて、私がしばしばブチ当たる話をベースに考えてみました。実は「システムの導入」が難しいのではない、という結論です。
人が減る
身も蓋もありませんが、記事事例のケースでは、<図-１>の本社担当者の仕事がなくなってしまいます。
会社側から見れば、人を減らしたり、プロセスを省力化することは、コスト削減と品質向上に寄与することになってウェルカムですが、当の担当者からすればたまったものではありません。
というか、現実問題、会社は簡単に人を減らすことは出できません。したがって、業務のやり方を変えて余剰人材が出た場合でも、「人員整理！リストラ！」となるのはではなく、配置転換などで「新しい仕事」を担当してもらうことになったりします。
ところが、長く仕事を続けてきた人材に対し、「あなた今日から新規事業企画ね」と振っても中々上手く行くものではありません。
働く側からすればモチベーションが下がるし、会社側からしても結局コストは下がりません。いいとこナシです。
であれば、「変わらずにそのままやろうぜ」という流れが出来るのはむしろ自然な流れと言えます。
習熟コストの問題
新しいやり方には学習コストが掛かります。そしてその学習コストは均一ではありません。
一言教えてすべてを理解する人もいれば、何度言っても理解が進まない人もいます。新入社員に教えるのと違い、背景となる知識や経験が各自異なるので、それに合わせた対応が必要になります。
その対応が出来なかった場合、各自が「自分のやり方」に固執してしまい、結局「メールで更新情報を送り続ける人」などへの個別対応が必要になってしまいます。
新旧システムが混在してしまうと、新規投資分の他、旧システムの維持もズルズルと必要になりダブルコストが発生、これまたいいとこナシです。
要するに何が言いたいかというと、「素晴らしい論理モデルのシステム」は理想ではあるけれども、それだけではいろいろ軋みが出て、実効性のある導入は難しいということです。
情報システムをデザインするということ
やっと表題の話です。話が長い。
情報システムをデザインすることには、「論理モデル」のようなものを作ることは当然に含まれます。
しかし、先に述べたように、それだけでは効果が出にくいのも事実です。
効果を出すためには、「組織の現状」に応じて、必要な手当てをしながら進めていくという作業が必要になります。
利害関係者となる部門や組織に焦点をあてて、必要があれば受け皿となる業務のデザインや、目指すべき方向の説明などを丁寧に重ねることが重要です。
以前こういう話をしたところ「それは情報システムの話じゃない」と指摘されたことがありましたが、まったくその通りです。
個人であればDropboxでもEvernoteでも思いつくままのノリで使ったらいいのですが、組織で情報システムを使う場合は、内部の利害関係者の不安を解消していくことも同時に考えなければなりません。
最初に「システム屋の目標は人減らしだ！」と思われてしまうと、現場の協力も得られません。
情報システムはデジタルで無機的なイメージがありますが、だからこそ、人や組織の問題を抜きに出来ないと考えています。
「情報システムをデザインする」ということは、結局、組織の問題に多かれ少なかれ入り込まないとならないということになります。
「それは情報システムの話じゃない」ということになってしまいがちですが、私にサポートできるのは、技術的な面だけではなく、その辺りも含めて効果に結びつける、という点でもあります。
最後は自己PRで終わりました。すいません。
ITと経営に関するお悩みはありませんか？
お一人で悩まれずに、些細なことだと思われることであっても、お気軽にご相談ください。
もちろん、お問い合わせメールへは無料で対応いたします。
