システム化の本質
私が唱える３ステップ経営改革は、法人営業・事業企画のエキスパートとしての経験と総務人事役員経験が基となっていますが、私が得た特異なスキルがそれらの経験を支えています。
それがシステム開発の経験で、それを通してシステム化するとは何か、その本質は何か、という根本思想に基づくシステム化・経営革新の他、実務面で業務の流れを俯瞰し見える化し業務効率の向上を図ることが出来ました。
何故、何も知らない新入社員の私が基幹システムプロジェクトに選ばれたのか
新卒で入社した際、私は電子材料事業部門の営業職として配属されたのですが、通常であれば特定の製品を担当する営業課に配属になるべきところ、管理室という経理・企画部門に配属となりました。実はこの当時、所属事業部ともう一つ、会社の大黒柱となっている大事業部が共同で営業情報システム開発を行うプロジェクトが立ち上がり、新入社員の私がそのメンバーの一人に選ばれたのです。
プロジェクトは非常に人望のある大事業部の管理部門長をトップに、電子材料事業部の営業課長がリーダーとなり、大事業部の経理エキスパート、システム管理マネージャーに営業担当者としての私が事業部側、つまり発注者側の業務設計メンバーとなり、情報システム部の課長が多数の開発メンバーを束ねるために加わるという構成でした。
私にとっては非常に名誉であり且つエキサイティングなことでしたが、私のように何も営業実務を経験していない者がそのような重要なプロジェクトメンバーであって良いのだろうかというのが率直な不安、疑問でした。
初期のミーティングで率直にこの疑問をトップにぶつけたところ、非常に驚くべき答えが返って来ました。
「何にも知らないからこそ君をメンバーに入れたんだ。余計な雑念の無い者が、この業務はどうあるべきかの理想形を描くことが出来る。仕事の始まりから終わりまで、あるべき姿を業務フローにして一筆書きで描いてごらん。
これまでのシステム開発は、情報システム部門が主体になって膨大な時間をかけて現状調査をつぶさに行って、その現状をシステムに置き換えるということが常態化していた。そのために、多数の不要な業務がシステムに置き換えられ、全体像が見えない業務の効率化からほど遠い結果を生んできた。
システム化するとは、業務を体系化することである。誰が見ても仕事の本筋が容易に理解出来るものにすることだ。
そのツールとしてコンピュータシステムを導入することで、一気に効率を上げることが出来る。
今回の開発では、君があるべき姿の業務フローを描いてごらん。一筆書きのような業務フローになるはずだ。その本流に、どうしてもすくい切れない例外を位置づけてごらん。それがプロジェクトで確定出来たら、それを各現場に持って行って、今の仕事をこのように置き換えることが現実的に出来るかを聞いて回ってごらん。
そうすれば、本質を見失わずに短時間で、実現性の検証が出来るはずだ。」
この衝撃的な答えに私は一気に魅了されました。この考えが、その後の人生でシステム化を考察する際、業務効率化を図る際の私の根本理念となりました。
そしてこの方針に則って私は自分のミッションを果たして行きます。
生産から倉庫への入出庫報告、受注から出荷、債権回収までの業務が全て一気通貫のシステムによって体系化されました。
私が描いた業務フローは、会議室を一往復する長さの、まさに一筆書きとなりました。
どんなメジャーなシステムにも無い画期的な「〇〇未報告」画面
システムには、経理エキスパートの発案で各業務フェーズでの「〇〇未報告」画面が設けられました。一度受注報告が入れば、債権回収が完了するまで、システム上、どの段階がクリア出来ていないか、残るタスクが何かが、一目瞭然で分かります。
システム稼働後、アシスタントの女性社員達に最も好評だったのはこの画面です。彼女達は、毎朝この画面を立ち上げ、今日のやるべきことを一目で把握することが出来、仕事の漏れは一切起きません。
後年になって世界を制覇したＳＡＰシステムやセールスフォースドットコムなどを使用する機会がありましたが、このような便利で本質的な機能を持ったシステムには出会ったことがありません。もし、システム企画をする方がこのブログをご覧頂く機会があれば、この情報は値千金ではないかと思います。
システム開発の王道であるコード設計と取引先概念の定義
合わせて、システム開発の王道である、製品及び取引先コード設計が3階層で緻密になされて行きます。取引先には大きく分けて３つの属性があり、販売先（お金を貰う先）、仕向先（実際の製品利用者）、納入先がそれです。その組み合わせを決済条件マスターに予め登録し、その組み合わせにある受注登録しか出来ないようにして管理します。
仕向先（製品利用者）毎の予算実績管理が営業の本質
販売先と製品利用者が同一である場合、販売先と製品利用者が異なる場合がありますが、この設計と運用によって、入金管理と実利用者への販売実績管理が当たり前に行えます。
商社毎の販売実績、実利用者への販売実績を製品群毎に把握することは非常に容易に出来ます。
システム設計と営業管理の両方の基本が欠落したメジャーシステム
近年世界で最も高いシェアを獲得しているセールスフォースドットコムを使用した経験がありますが、このシステムでは販売先としての属性を個別の取引先マスターに入れ込んで行くのですが、実運用上は実行不能でした。そのため、販売先単位での実績、仕向先単位での実績を把握することがシステム上では不可能で、且つこのシステムでは最も法人営業で必要な、取引先毎の予算実績管理の機能が無く、この不足を補うためにダウンロードデータのエクセルと毎週格闘する必要があって非常に閉口しました。
この会社はシステム開発の素地、及び法人営業の本質的経験の無いところで、ユーザインターフェイスのビジュアル化と広告で顧客を獲得して行ったことが窺われます。
情報システム部門の限界
先ほどの自社システム開発では、各関係部署での新業務フロー検証のヒアリングは順調に進んで、私が描いた業務フローが各部署で問題なく適用出来ることが確認出来、プログラム開発をいよいよ進めようという段階で、ある工場の情報システム部門が、このやり方では実現性に不安があると言いだしました。この段階で私の尊敬するプロジェクトトップが他部署へ異動となっていたため、プロジェクトは一旦彼等の言い分を受け入れて、彼等が考える方法で実現性検証をやって貰うことにしました。
結果として、プロジェクトが半年遅延することとはなりましたが、我々の描いたフローが彼等から見ても適用可能との結論に達し、開発が進められました。
この間に、本社情報システム部門は、2か所の大工場、数か所の倉庫については、所謂分散処理をするのが望ましいとの判断から、個別のコンピュータを配置する構成とすることを決定します。プロジェクトの一員として、その会議で私は分散処理に大反対しました。同じシステムフローでありながら、本社と工場と倉庫各々コンピュータの機種が違うため、開発に膨大な工数がかかる上に、一つのシステム変更が起きると３つのプログラム開発が必要となる不効率、更に本質的には、どこかの事業所のコンピュータが止まった場合、システム全体としては機能しなくなるため、このような分散処理はシステム上のリスクが高すぎる、
それを回避するためには、本社コンピュータ一本で集中処理を行い、それを二重化すべきだと強く主張したのですが、あいつを情報システム会議に出させるな、という話になって、彼等は分散処理を取ることを決めてしまいました。
H工場で生産された製品がK倉庫に転送され在庫されたりしますが、K倉庫のコンピュータが止まった場合、システム全体として見た場合、正しい在庫を把握することが出来なくなる訳で、場所を分散するだけのシステムは本質的に何のリスクヘッジにもなっていません。
自社開発システムの成功とその後のキャリアへの寄与
これらのように旧来の情報システム部門的な考え方が、本質から外れていると言わざるを得ない部分が多々あるものの、
プロジェクトは開発を終え、私は厚さ3㎝ほどの全体像と個別操作はこれ一冊で分かるA4版マニュアルを作成し全個所に配布して、従来業務を新システムに成功裏に移行することが出来ました。
ここでの経験が、その後のキャリアにおいて、
課員12人の業務を業務フローで見える化して、業務の重複を排除し、6人を本来の業務責任部署に戻すことで6人のチームにスリム化したり、
生産管理システムの導入を行ったり、
システムインテグレータとしては安易な分散システムを1か所に集中した上で二重化するのが本質的ソリューションである、といった提案をする際に活かすことが出来た他
業務フロー化することで、作業手順書をビジュアルにして分かりやすくして社内の標準化を図ったり、改善点の協議を行う際に役立てることが出来ました。
本稿のまとめ：
システム化の本質は体系化である、
システム化を行う際の手順はまず理想形を一筆書きの業務フローで描き、それの実現性を検証する方法が最も本質から逸れずに効率化が出来る、
業務フローによる見える化を図ることで、標準化・共通認識形成が実現出来る
以下をクリックすると著作及び経営革新実践プログラムのご案内をご覧頂けます。
