標準化って言うほど簡単じゃない / Standardization is not easy as it is said

全拠点の業務標準化を通じて経営情報の見える化を図り、より鮮度・精度の高い情報をもとに経営判断するための仕組みを導入するプロジェクト。

カイゼン文化のある会社での業務標準化、意思決定者の不在、本社－支店間の力関係が一個人の人間関係に依存、各国の税制等複雑な固有要件の存在、など幾多の課題が待ち受けるなか、

システムの開発から導入までを支援したお話。

前段

自動車部品会社において標準システムの世界全拠点へ展開するプロジェクトに参加したことがある。

計画は5年で全世界100拠点以上へ展開するのにプロジェクトメンバーの人数は各部門から２－３人という絵に描いた餅のようなプロジェクトだった。

私はシステムの開発終了前から新しく立ち上げる拠点への導入までを支援した。

このプロジェクトは業務およびシステムの両輪で標準化を進める方針であり、生産管理、購買、販売、在庫管理、会計の5大領域で進められていた。

私は会計システムのPMO一員として支援していたこともあり、会計システムにおける標準化の話をしたい。

一般的な標準化の定義と目的

まず標準化とは、JISで次のように定義されている。

「関係する人々の間で利益又は利便が公正に得られるように、統一し、単純化を図る目的で、もの（生産活動の産出物）及びもの以外（組織、責任権限、システム、方法など）について定めた取決め。」

要はバラバラになっているものを統一することなのだが、関係者が増えれば増えるほど、この単純なことが非常に困難になる。

次に目的としては、作業内容を統一することで属人化から脱し、品質を均一化させるということが多いと思う。

そのほかには、ベストプラクティスを標準とすることで作業を効率化出来たり、何か問題が発生した際の原因追及しやすいといったことがよく挙げられる。

また、業務を標準化すると人材が流動的にできる。どこに行っても同じ作業になるので人員不足時に他拠点から派遣したりすることが容易になるのだ。

私が参加したプロジェクトにおける標準化の目的は、経営情報の見える化である。

経営層が経営判断する際に必要となる会計情報を可視化できるようにしたい。そのためには経営指標に関わる会計情報の標準化が必要であり、つまりは上流工程の業務の標準化が必要になるというものである。

会計情報は業務プロセスの最後の最後

プロジェクトを困難にするポイントは書き出せば、切りが無い。

・導入できる人材が不足（ヒト）
　リモートでの展開作業（ブリッジエンジニアの育成）
　部門をまたいだ上流工程まで業務整備が必要
・個別要件をいかに取り込むか（システム）
　国ごと固有要件
　拠点ごとの成熟度相違
　製品ごとに考え方が異なる
・すごすぎる日本本社の業務力（業務プロセス）
　グローバルシステムの設計思想とそぐわない日本の業務プロセス
・決まらない（意思決定）
　誰が決めるのかが決まっていない
　どうやって決めるのかが決まっていない
　社内人間関係のしがらみ。
・過酷な生活環境（プロジェクト環境）
　発展途上国での導入生活

今回は私が担当したのが経理システムである点にフォーカスして記載する。

何が最も困難にさせているかというと、目的である経営情報を会計情報をもとに出そうとした際、会計情報の粒度・精度・鮮度が異なることに気が付く。

粒度とは、一言で言えば入力情報の単位である。
例えば、請求書の最終的な合計金額だけを入力しているのか、明細項目１つ１つを分けて入力しているのかで出てくるデータの大きさは異なる。

精度とは、ミスなく入力できているかである。
例えば、請求書の数字を転記する際に数値を間違えていないか、という初歩的な話もあるが、それ以上に大きいのは、どの勘定科目（どういった用途で発生した売上・費用か）に紐づけて仕訳を打つかは、ルールはあれど個々人の判断になる。

鮮度とは、事業部門で発生した数字がリアルタイムにシステムに入力されているかである。
例えば、営業部門は製品を販売した際に、どの段階で売上が立ったと言えるのか、これすら明確に決まっていないこともあるが、月初に契約になったにもかかわらず、月末にまとめて経理に届くこともある。1か月近い情報の遅延が生まれることになる。

これら３つを上流の業務（営業や調達、生産部門、場合によっては顧客や仕入れ先業者にまで依頼する必要がある）に遡って標準化することが求められている。

振り返って思う会計情報標準化の進め方

まず、経営情報から必要な会計情報へ分解する。

次に会計情報の元となる情報はどういったどのタイミングで計上すべきか、またどこの部門で情報が発生しているのか？を整理する。

そのうえで、対象部門に赴き、関連する業務プロセスを明確にする。

業務プロセスが明確になったら、必要なタイミングで経理部門へ回るようにルール化して周知・啓蒙活動を行う。

一見、スッキリやることが明確なようだが、ここまでで道半ばである。

この作業を標準業務の設計段階で実施しなければならない。
それもいくつもある拠点に対してである。

もちろん売上貢献の大きさや経営上主要な拠点を優先して、小さな拠点は準拠してもらうなどの方法はある。

しかし、私が参加したプロジェクトではこれがうまく進まなかった。

理由はいくつもあるが、一番の理由は、欲しい経営情報の定義がままならないことだったと思う。

結果的に最初の１、２拠点目で、標準業務の設計につながる業務プロセスを整理しながら導入するという強行をし、プロジェクト中止を回避しながら導入、以降につなげるための整備をしていったのである。

プロジェクトを離れた後の状況

私は２拠点への導入を支援し、本プロジェクトを離れることになった。

その後、プロジェクトは振り返り期間として、標準業務の設計を進めた。２拠点に導入して得られた業務知識をもとに標準化すべきポイントをリスト化し、他の拠点に配布したのである。

数か月のうちに他の拠点の現状を大まかに把握することができ、展開スピードが格段に向上したと聞いている。

あるべき展開プロセスに戻ってきたわけだが、ここから難易度は次のステージに進む。

なぜなら、展開拠点が増えると導入済拠点の業務・システム双方への影響を調査したうえで変更する必要があり、時間も労力も要するのである。

プロジェクトを離れて数年が経つ。

苦戦しながらも着実に展開していることを願うばかりである。

Preface

A project for auto-mobile parts company to roll-out standardized global system to their every factory and office all over the world.

In the project, we worked as a PMO (Project Management Office) to manage whole roll out project in which we mainly support accounting system implementation. We had other systems such as production, purchase and inventory management system.

There are many challenges for the project such as tough project physical environment, lack of resources, gap of operation and system concept, poor decision process, complex human relationship, etc.

In this note, I would like to focus on the difficulty of selecting requirements to standardize which is one the hardest parts of roll-out project.

General concept of Standardization and its difficulty

The definition of standardization is the process of implementing and developing standards based on the consensus of different parties that include not only project members but also stakeholders who may be affected by the project.

The processes is as below.
1.Clarify the objective and set up the goals
2.Define To-Be and analyze As-Is
3.Find the gaps between Tobe and Asis, and build up the resolutions
4.Create the rollout plan and implement the solution

When project member analyzed As-Is of each site, they realized how standardization project was difficult to proceed.

Because, the business process was different in each site.
  timing was different
  frequency was different
  size/unit was different

Basically, when they establish new site, their mother factory members plan and implement process and rules based on what they do at the mother factory.

However, because of difference of physical shape of factory, local business practice, members' skills, etc. process has been changed (maybe improved) under the name of Kaizen.

In this Japanese Kaizen culture, after implementing standardized process, staff cannot change their process easily like before. 

the process is managed globally under Centre of Excellence team who understand the business processes of all sites.

Financial information is the last part of process.

We mainly support financial system.

Financial information is one of the most important information for management member however it is the last part of whole business process and affected by every process preceded before posting financial information by finance team.

This means to standardize financial info, we also need to standardize system and business process of purchase, sales, production, inventory management, etc.

For example, 
When can we post account payable / receivable?
it depends on how timely purchase and sales team, or even their customer and vendor pass document to finance team.

Ideal process of standardization

firstly, breakdown management info into required accounting data.

Then, organize information
 when we should recognize these data; and
 which dept. controls these data.

Interview the dept. and clarify its business process.

Once the business process is clarified, create standardized process and implement rules for the dept.

We have to collect process information from each dept. in all sites, especially sites which provide huge contribution to group sales.

My project was not carried out smoothly. It didn't follow ideal process.

There were several reasons but main issue was that management info was not completely defined.

As a result, we forced to implement to 1st and 2nd site and created standardized process based on them to avoid ceasing the project.

After leaving the project

We left the project after supporting to implement to 2 sites.

After that, they had time to define standardized process and distribute checklist to other site before implementation.

With this, I heard that they could implement much more smoothly returning back to ideal process.