成長段階が成功して広くEUCが定着してくると、新しい問題が発生してきます。
(1)EUCの過剰利用
この段階になると、情報はEUCで得るものだという認識が定着しています。それが、かえって不適切な利用になる危険があります。無駄遣いのチェックが必要になります。
本来は、基幹業務系システムとして行うべきことを、EUCで行うという無駄をしていることがあります。月次の経営会議で報告する資料の中には、各部門が同じ形式で定例的なものもあります。それを基幹業務系システムとして出力すればよいものを、わざわざ各部門が個別にEUCで作成するような重複作業の無駄が生じます。
カンでなくデータで語ろうというのはよいことですが、つまらぬことにまでデータを得ようとします。「〇〇得意先には毎月どの程度の売り上げがあるんだい」とその得意先の担当者に聞くと、やおらパソコンに向かい、過去12カ月の売り上げファイルから計算して、15分後に「1234万5670円です」と答えます。ところが、〇〇得意先はこの担当者の大得意なので、担当者は「ほぼ1000万円強ですね」と即答することもできたのです。
ユーザーの過度体裁愛好症も危険です(参照「第9回 情報システム部門の生産性が上がらない理由」)。ユーザーはベタ打ちの数表でも問題を発見できるのに、凝ったグラフにしたがります。ユーザーの仕事は、問題発見をしたらその解決をすることなのに、それを放っておいて、キレイなレポートを作成するために時間を浪費します。
しかも、周囲はパソコンにかじり付いている人をサボっているとは思わず、熱心に仕事をしていると思いがちです。パソコン1台を運用する総費用をTCO(Total Cost of Ownership)といい、それがパソコン購入費用の数倍になることが指摘されていますが、このような無意識のサボタージュを加えたら、TCOは一般に考えられているよりはるかに大きいものになるでしょう。
(2)公開ファイルの管理
とかくEUCは管理の眼が行き届きません。公開ファイル提供方式が望ましいといいましたが、その公開ファイルが無計画に乱造され、その維持管理が大変な作業になる危険があります。
初期段階では、全体のデータ体系などは考えずに、限定されたユーザーの限定された分野に公開ファイルを作成しました。成長段階では、多数ユーザーの多様なニーズに応えるために多くの公開ファイルを作成しましたが、その中には似たような内容のファイルが多くあります。この状態を放置しておくと、どのような公開ファイルがあるのか、そのファイルの項目の定義がどうなっているのか分からなくなってしまいます。
この段階では、公開ファイルという概念を発展解消するべきです。EUCのためというよりも、全社のデータを統一的・体系的に整理して管理することを主体とするべきです。その必要性や方法は、「第14回 データウェアハウス中心アプローチで問題解決しよう」を参照してください。すなわち、全社のデータを統一的・体系的に整理したものを、全社のデータの保管庫としてのデータウェアハウスに蓄えます。そして、基幹業務系システムとは、データウェアハウスのデータを正確にルールに従って提供するシステムであり、情報検索系システムとは、データウェアハウスのデータを適宜データマートに転送しておき、それをユーザーがEUCで利用するシステムだと位置付けるのです。
(3)業務統括部門にEUC推進組織を
初期段階から成長段階に移行する段階で、情報システム部門や各部門にEUC推進組織を設置しましたが、成熟段階ではさらに、営業本部や本社経理部のような業務統括部門にもEUC推進組織を設置するのが効果的です。
情報システム部門の推進では、どうしても情報技術的な分野が中心になりますし、各部門のキーパーソンによる推進では、日常的な業務改善が中心になります。経営戦略に基づいた革新的な活用をするには、経営者と普段から接触する機会の多い業務統括部門がEUCに関与することが重要です。
先に「個別帳票メニュー提供方式」は不適切だといいましたが、この方式はユーザーにとって便利です。情報システム部門はユーザーの要求をはねつけることが不得手であり、その要求に応えようとしたがり、その結果、情報システム部門の負荷が増大してしまいます。
業務統括部門は、各部門の業務の仕方を決定し管理する機能を持っていますので、不適切な要求を却下するのに説得力があります。また、ある支店から効果のある要求が来たときには、全支店でも利用できるような個別帳票メニュー方式に自分たちで作成することもできますし、さらにこの要求が定例的に必要なものであれば、基幹業務系システムとして対処するように情報システム部門へ提案することもできます。
業務統括部門のEUC推進組織は、情報システム部門とユーザー部門のローテーションのバッファとしても役立ちます。情報システム部門から直接ユーザー部門に転出するのでは業務知識も不十分ですし、その部門で何が懸案になっているのか分かりません。業務統括部門はそれらを知るのに適したところですし、業務統括部門には経営者もよく来るので、経営方針と業務、業務と情報活用の関係も理解できます。そのような知識は、ユーザー部門でヒーローになるのに必要です。
逆に、ユーザー部門から情報システム部門へ来るときも、業務統括部門で情報技術や経営方針などを身に付けて、出身部門へのサービスをすることにより、情報システム部門の雰囲気を理解できます。そのような人は情報システム部門が大歓迎するでしょう。
(4)次世代教祖の育成を
EUCが日常的になるに伴い、初期段階の教祖や使徒のような問題意識や変革への挑戦の熱意がなくなってきます。
データ体系の整備や分析能力の向上は、単にEUCだけではなく、基幹業務系システムを改革することにもつながりますし、さらには経営戦略にも影響を与えます。多様な分野で挑戦をする教祖を育成することが望まれます。
この記事に対するご意見をお寄せください managemail@atmarkit.co.jp
木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」(ともに日科技連出版社)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
Copyright © ITmedia, Inc. All Rights Reserved.