ヒットコラボ代表。地頭力にて、IFRSを業務視点より考察する。

第9回 現場革新がプロセス革新を生む。IFRSは原則主義

»

 現場革新には、以下の3つのキーワード がある。

  • 利用者側が仕組み改善を行う自覚
  • モノづくり(現物)、コトづくり(設計情報などのソフト)を一気通貫にする横串組織
  • 現場分析・現場改善手法とリンクした情報管理

 今回は、IFRSの話題から離れるが、現場改革について考えてみたい。

■仕組みをプラモデル化させない

 ここでいうプラモデルとは、人を乗せて走らなかったり、動かなかったりするものの例えである。

 開発作業では、一生懸命に精査し、複雑なプログラムを組み、画面も見やすく利用者側も期待していた。なぜ動かない仕組みになったのだろうか?  現場をよく知っているスタッフが、つぶやいたのはこうだ。「現場にふさわしくない仕組み、どこかが『ずれ』ている。 作ったのはGMの大きなタイヤがある自動車ではないか、燃費が悪く、ずうたいばかりが大きく、小回りがきかない……。そうなると、結局、破たんしてしまう。走らない見かけがカッコ良いだけのプラモデルは不要で、カローラ程度を目指せばよかったのではないか……」

 開発はうまくいっても、開発当初のスタッフが配置転換されたり、退職したり、他社に丸投げしたりしたため、メンテナンスが行き届かなくなり、運用でプラモデル化していくケースもある。

 このような事象にならないよう、仕組みを進化させ、維持し、管理するにはどうすればいいのか?

 少なからず、失敗は存在するが、粘り強く改善していく地道な努力が必要である。それらを理解するトップの存在は不可欠である。

 それでは、仕組化の側面から「現場革新」を考えてみよう。

運用コスト削減につながる自主自立システム

 上記、プラモデル化の背景は、システムは「システム屋に任せる」と、言葉には出さずとも、社内にそのような空気が流れている場合に起こり得る。

 IT化における現場革新とは、各部門スタッフの意識改革と熱意などの現場力に依存する。すなわち、仕組化の当事者は現場にあることを共通認識として、オーナーも含め、プロジェクトメンバーの腹に落ちていることが必須である。

 利用者側も、IT提供側も強い信念として、以下のような課題を意識しておけばいいだろう。

 業務の進化に同期し、仕組みも変化させなければ、あるべき業務プロセスと現実が乖離(かいり)し、使いものにならない仕組みになる。従って、仕組みを変えたい当事者が改善できる。

 また、そのシナリオを描き、外部に修正依頼すれば、改善に至るまでのコストが削減される。専任のシステムスタッフを配置できない企業規模の場合、将来を見越し、外部のサポートを含めた、体制と役割を検討すべきである。

横串組織と情報管理

 以前に触れた、クロスファンクションチームのおさらいになる。スピーディかつ伝言ゲームにならない連携力だ。

 さらに、「速く」ではなく「早く:フロントローディング」を実践できる組織になるためには、得意先や協力会社も社内の1部門としてとらえ、コラボーレーション型組織の在り方とその業務運用について、検討することが必要である。

 その運用の中で、BOMの構成情報の見せ方や、部門間でフィードバックする情報の在り方などのさまざまなドキュメーテーションをコミュニケーション媒体として検討する必要がある。

 ここまで、ITシステムに対する利用者側の前向きな姿勢が、企業システムを使える仕組みに変質させていくということをお分かりいただけただろうか。

 副題に「IFRSは原則主義」と記した。適用範囲や方法は自由度があるという解釈である。

 言い方を変えれば、原則はあるが、模範解答はない。すなわち、自社のあるべき姿を定義しなければならない。他社の模倣では、将来に大きな災いをもたらすかもしれない。 

 また、IFRSは投資家からの視点であり、従業員や経営者が見る視点と異なるのは、明白である。

 従って、経営視点から見た、管理会計などPDCAが回せる仕組みとシンクロしなければIFRSに投資したメリットがないばかりか、経営そのものの羅針盤を失うことになりかねない。

 仕組化の方針は、財務部門だけでますます決定できないことになる。情報システム部門でも同様である。 

 例えば、原価に影響する償却費計算の基準となる耐用年数は各企業の裁量で決定できる。

 減損処置や基準を毎期見直しするなど、実態に即した対応をしなければならない反面、メリットは数多くあるはずである。その辺りをディスカッションすることが重要なのはいうまでもないだろう。

 
Comment(0)

コメント

コメントを投稿する