FC2ブログ
page top
モノづくりを知る
みなさん、こんにちは。

皆さんは「工場見学」を体験されたことはありますか?
私はお客様をご支援させて頂く際には、必ず工場を見学させて頂きます。非常に数多くの現場を拝見させて頂いております。
しかし、仕事とは関係なく工場見学が体験できる場もありますよね。
私が住んでいる愛知県でも、ビール、牛乳、酢、新聞などさまざまな工場見学・体験できる企業があります。
ご参考までに、全国の工場見学を案内しているサイトはこちらです。

工場見学ナビ

直接現場を見る、体験するということは非常に重要なことだと思います。
現地・現物・現実の基本ですね。
しかし、いくら役立つと言っても物理的な問題もあり、全国の工場を巡るのは大変なことです。
そこで今回は、既にご存じの人もいらっしゃるかも知れませんが、科学技術振興機構が主催するサイエンスチャンネルをご紹介いたします。
お子様がいらっしゃる方はぜひご一緒に楽しく現場を体感して下さい。
番組検索欄から「製造」などと入力して検索すれば、いろいろなモノづくり番組が見られます。
私は殆どの番組を見ました(暇なのでしょうか・・・)。

サイエンスチャンネル

知ったこと、興味が持てたこと、疑問に思ったことなどを体感した皆で話しあえるといいですね。
「知る」ということは成長に繫がります。

みなさん、未来に向って叡智を出しましょう!!
スポンサーサイト



page top
三現主義について考える
みなさん、こんにちは。

今回は「三現主義」について考えてみます。

製造企業で働いていらっしゃる方ならよくご存じだと思います。
「現場」「現物」「現実」のことです。
「現場」に直接行って、「現物」を直接見て(触って)、「現実」を知ることです。
問題発見・解決の基本と言われています。
しかし、頭では大変よくわかっているのにこれが最近ではあまり行われていないように感じています。
色々と要因はあると思います。
例えば、
 1.元々そのような習慣がない
 2.情報技術が発達した
 3.現場が物理的に遠い

1.元々そのような習慣がない
これは大変不幸な事です。このような習慣がない企業風土、習慣であれば未解決の問題が山積みとなっている場合が多いと思われます。
また、習慣が無いわけではないけれど、多忙を極めていてついつい電話確認で済ませてしまう、報告者の報告内容をそのまま受け入れてしまうという場合もあると思われます。
報告者が「悪いこと、都合がよくないことは報告しない」なんて絶対にあり得ないと思っていてはマネジメントとしてはよろしくありません。

2.情報技術が発達した
ITを活用して経営情報を可視化するという流れは昨今当たり前となっています。確かに、今発生している問題や実績が直ぐに見えない、限定的にしか見えないということで困っている企業はたくさんあります。見えない・見えにくいよりも、確実にタイムリーによく見えた方が良いに決まっています。しかしITで可視化出来たといって安心していてはいけません。
何故なら、蓄積された情報がすべて正しい、事実を反映した情報とは言えないからです。入力者だって間違えたり入力を忘れたりします。
また、見えているのはあくまでもデジタル化が可能な情報のみであり、デジタル化が出来ないアナログな情報はIT化したところで見えません。つまり可視化、可視化と言いますが、可視化できたとしても不十分なのです。これが十分に認識されて上で運用されていません。
情報伝達・コミュニケーションが電子メール主体という今日の業務運営にも弊害があります。現地へ行かず担当者にメールで連絡をもらう。これで確認OKとしてしまうというのは、1項にも関連する問題点と言えますね。
因みに、報連相のボリュームが膨大化するメールですが、件名がよくわからないものが多いと感じています。
問題の報告なのか、相談なのか、提案なのか、資料のレビュー依頼なのか・・・
だいたい「○○について」という曖昧な件名がよくありません。各企業で件名と重要度・緊急度の設定には工夫することをお勧めします。

3.現場が物理的に遠い
今日の販売・生産・物流拠点のグローバル化に伴い、現地が物理的に遠くなっているのは事実であり、本社ですべてをコントロール出来なくなりつつあります。
例えば、こちらが稼働中の日中でも時差があり先方は夜中ということもありますし、相互の信頼関係が薄く適切な報告が受けられない場合もあります。
この場合は現地の教育を徹底し、現地で三現主義を徹底させ、証跡を確認できる仕組みを構築することが重要です。この時に重要な点は「何が起きていて何が原因なのか」の追究と報告です。決して「誰が悪いのか」ではありません。日本以外でもこの犯人探しが習慣化している地域はありますのでこの点を押さえておく必要があります。
自分が現地に行かなくても、信頼できる現地のマネージャーなりが「三現主義」を実行できれば、そしてそれが信頼に値するのであればよいということです。

但し、いくら「三現主義」と言っても常に現場を駆けずりまわっていてはいけません。これは効率が悪く時間をムダにします。時々、会社で汗を流すことが仕事と勘違いしている人もいますが、汗の量、走った距離ではなく、付加価値をどれだけ高めたかで仕事の成果を計測しなくてはいけません。
大切なことは
 - 絞り込む
 - 仮説を立てて「三現主義」で検証する
ということです。勿論、とにかく現場に行ってという姿勢も時には大切なのですが、上記3項の場合には場所にもよりますが、かなり高額な経費がかかる場合もあります。出来れば事前に出来ることは準備しておくべきです。

ある企業で業務改革と基幹システムの再構築を行いました。本番を稼働しましたが、比較的問題なく、順調に見えます。以下は私とお客様との会話の概略です。詳細に記録をとっていませんのでこんな感じで会話したとお考え下さい。

私 「問題はどの程度、どの部署で発生していますか?」
お客様 「大きな問題は発生していません。問合せは結構ありますが、電話やメール連絡でだいたい済んでいます。」
私 「各部署の巡回は実施していますか?」
お客様 「やっていません。手がまわりませんし、それに毎日、朝礼でプロジェクトメンバーから状況報告をしてもらっていますし、情報収集の徹底も指示していますから、大丈夫と思っています。」
私 「操作のミスはどの程度発生していますか?」
お客様 「特にミスの発生頻度は集計していません。」

その後、私は教育時の職場別個人別成績を確認しましたが、特に成績が悪い人が集中している職場は無いようでした。
そこで1日当たりの処理件数(トランザクション)が多い職場を探した所、購買部門と倉庫部門がありました。
早速プロジェクトリーダーにお願いしてこの2つの部門へお伺いしました。
購買部門は人数が多く、一人に多数のトランザクションが偏っているということはありませんでした。
まぁ、中には新しい業務に慣れていないため、頻繁に隣の人に聞いているという作業者もいらっしゃいましたが。
次に倉庫へ行きました。そして問題が発見されたのです。

作業者の方に作業状況を見せて頂いたのですが、新しい業務は当然行っているのですが、この後に以前の伝票処理も行っていたのです。
私 「なぜ新しい業務だけでなく、古い業務も行っているのですか?」
作業者 「そう指示されているからです。」
私 「誰にそのように指示されているのですか?」
作業者 「リーダーです。」
そこで職場のグループリーダーに来て頂きました。

私 「どうして作業者に古い業務を指示しているのですか?」
リーダー 「伝票処理をしないと、処理済の伝票と未処理の伝票がわからなくなるからです。」
私 「新しい業務でそれはやっていますよ。この画面で処理してます。二重処理になりますし、だいいち、古い方で処理してももう使われませんよ。新しい業務の流れや処理の教育は受けましたよね。」
リーダー 「教育は受けましたが、古い業務を廃止するとは聞いていませんでした。」
私 「わかりました、今日からやめましょう。お願いします。」

その後、倉庫のその他の業務も確認しましたが、これ以外に2点ほど問題がありました。
プロジェクトルームに戻り、プロジェクトリーダーに各職場を巡回するスケジュールを作成するようにお願いしました。単に巡回するのではなく、各職場の点検ポイントを整理することもお願いしました。
更に、職場毎に集まって頂き、再度新業務の確認会合を開催することも決めました。
プロジェクトリーダーには承認を頂きました。しかし倉庫の業務実態についてはショックを受けたようです。
倉庫のような実態は他の部署でも発生している可能性があります。これからその点を点検していかなくてはなりません。

問題が発生した時は、絞込みと仮説を立てて「現場」「現物」「現実」を実践すべき事例ですね。

みなさん、未来に向って叡智を出しましょう!!
page top
目的の明確化を心掛ける
みなさん、こんにちは。

今回は、以前支援させて頂いた、基幹システム強化活動を中心に、目的明確化の重要性について考えてみたいと思います。

そのプロジェクトは、事業基盤強化のための業務改革ではなく、基幹システムの刷新が主となる活動でした。
ただし、プロジェクト活動のテーマは「基幹システムを標準化・統合することにより業務全体を強化する」でした。
当然、活動の主役は顧客とシステム構築を担うITベンダーです。
採用が決定されたのはERPパッケージでした。

まずパッケージの概要説明、次にオペレーションを伴う機能説明が行われました。
そして、ベンダーから顧客へのヒアリング、業務フローの素案提示がされます。この業務フローに基づき詳細の検討が双方で行われます。
顧客からは様々な質問や要望が出されます。
「この様な機能はパッケージの標準として提供されてるのか」
「この項目をこの画面に表示して欲しい」
「この様な帳票が出力できないと困るんだが」
「現状ではこの順番では処理していない、反対にして欲しい」
などなど。
更に作業は進み、パッケージで取り扱う情報項目(管理データ)の説明がなされ、現状のシステムとパッケージとの相違点を確認します。
顧客側ではこの説明・確認をもとに、各職場で情報の過不足を整理します。後日、再度会合が開催され、過不足情報の検討が行われます。
ここでベンダーは慌ててしまいます。パッケージで定義されていない情報項目が多数要求されのです。
要求された情報項目を削減できないかとのベンダーからの確認に一歩も引かない顧客。そして遂に爆弾発言が飛び出してしまったようです。
「そもそもこんな機能もデータも持っていないパッケージを何故我が社は選定したのか!」と。
寅さんじゃありませんが、『それを言っちゃぁおしまいよ』の状況です。この人もちゃんと選定作業に参加していたのですから。
この後、顧客とベンダーとの間には溝が出来てしまい、会合も重たい空気が漂うようになってしまいました。

結局、不足機能や不足データは十分に精査した上で、追加するという方針が策定されました。
精査の管理は顧客プロジェクトの事務局が担うこととなりましたが、実際には精査など機能していないも同然です。
事務局は各業務に精通しているわけではありません。
例えば生産チームのメンバーが「この機能がなければ業務がまわらない」と言えば承認するしか術はありません。
結果として追加・変更要求のほとんどが承認されました。
追加・変更要求の削減は10%にも満たない結果となりました。

さて皆さんはこのような経験をしたことはありませんか?
どこが問題で、どのように活動を進めるべきだと思いますが?
少しこの先を読む前に問題点と改善方向について書き出してみませんか?


さて、書き出し終わりましたでしょうか。
点検していきたいと思います。
 問題点1. 活動を進めるにつれて当初の目的が忘れられてしまっている
 問題点2. 上記の問題が発生しているにも関わらずリーダーをはじめ誰一人目的の確認と活動の軌道修正を行な       っていない
 問題点3. 現状の業務を肯定して追加・変更要求を作成しているが、現状業務にムダはないか、本当に必要なの       の検証がなされていない


まず、問題点1についてもう少し詳しく考えてみましょう。
パッケージを導入する際のパターン大きく4つ挙げられます。
  1.まず業務改革を実践し、その後にパッケージを適用する
 2.選定したパッケージの標準機能に業務を合わせる(パッケーシ標準機能の実装が業務改革と見なす)
 3.現状業務を大きくは変えず、現状業務にパッケージを合わせる
 4.業務改革の姿をデザインしながら、うまくパッケージを適用する

さて、今回の事例企業は一体どのパターンを目指したのでしょうか。
実はこの点が統一されておらず、あるメンバーは2、あるメンバーは3と考えていました。

次ぎに問題点2についてです。早期段階でどのパターンでパッケージを導入するのか顧客プロジェクトチーム内で議論・共有できていたなら手戻りは軽減されたはずです。そのためには、そもそも何のためにERPを導入するのかにリーダーが気付かなければなりません。活動が思うように立ち行かなくなくなった場合は、必ず原点に回帰するということが肝要です。この点は現在特命を受けてプロジェクト活動に従事されている皆さんも十分に留意されるべきでしょう。
工夫としては、プロジェクトルームがあれば、プロジェクトの目標、目的、心構えなどを貼り出し、週に1度でもよいですから、全員で点検することです。よく貼り出しはするけれども点検は個人任せというプロジェクトがありますが、これはいけません。「見える化」の失敗事例です。

問題点3についてです。これは客観的な第三者が不在ではなかなか難しい事です。当事者にとって現状を否定することは容易なことではありません。特に入社・配属された時から今の仕事のやり方を叩き込まれた人に現状を否定することなど出来ません。仮に否定できたとしても代替案を立案することは相当にハードルが高いことになります。そのやり方以外に試した経験が殆どないのですから。また、代替案がポンポンと湧いてくるのであればとっくにそれをやっているでしょうから。やはり日頃からの「組織的」訓練が大切になります。
また、これはベンダーにも責任の一端はあります。現状通りの要求に対して、このように工夫すればパッケージの標準機能で業務の標準化は実現できますよという提案が不足していたのですから。
これこそ、ベンダーの貴重なノウハウであり、組織的に共有すべき資産と私は思うのですが・・・

さて、では業務をどのように棚卸ししたらよいのでしょうか。
いかにパッケージに業務を合わせると言っても、すべてをあわせる訳にはいかないのが現実です。事業としてここは中核的業務のためどうしてもパッケージには合わないというところがあります。この点は業界や業種によって同一ではありません。
整理のポイントは「目的」です。
 -この業務や機能は何を目的として必要なのか?
 -この項目は何を行うために必要となるのか?
 -それは誰にとって必要とされるのか?
 -それが実現したらどうなるのか、実現されなかったらどんな弊害がどの程度のインパクトで生じるのか?


次に業務改変についてですが、改変に際しては以下の4つの原則で検討する事が大切です。
 -排除の原則:不要、過剰、重複、不明な仕事はやめる
 -結合の原則:前後の仕事を結合する、他部門と一緒に仕事をする、最も効率的な単位で仕事をする
 -交換の原則:作業のやり方、順序、方法論、組織を変える
 -簡易化の原則:1枚でも減らす、1箇所でも減らす、1回でも減らす


システム構築活動で注意しなければならない点は、作業が佳境に入ってくるとどうしてもシステム構築が目的的に考えられてしまう点です。
プロジェクトリーダーはプロジェクト内の空気や匂いを敏感に察知し、怪しくなってきたら必ず原点回帰を目指さなければなりません。
つらいのは、メンバーの力量が不足しているために自らが実務者としてシステム構築作業にのめり込まなければならない状況が発生する時です。
やはり客観的第三者の支援は不可欠と言えます。

さて、私はこの混迷した状況に陥っている時に、別のプロジェクト支援をさせて頂いていたのですが、顧客の役員様からこちらの支援も要請され、プロジェクトの立直し支援をさせて頂きました。
プロジェクト活動に従事されたメンバーの皆さんは何ともご苦労されましたが、その分得るものも大きかったと思います。
しかし、しなくてもよい苦労は出来れば避けたいものです。

目的を常に念頭に置くということでプロジェクト活動も日々の業務も飛躍的に効率的になるはずです。しかも大した労力やスキルは必要ありません。新しい仕事を任されたら手帳などに書き込でみましょう。

みなさん、未来に向って叡智を出しましょう!!
page top
マネジメント リーダーシップ 役割の重要性
みなさん、こんにちは。

今回はマネジメントとリーダーシップについて考察してみたいと思います。
企業の改革を支援させて頂く際には、必ず改革のプロジェクトを編成して頂きます。
10年程前であれば、専任メンバー体制でプロジェクトを発足し、毎日プロジェクトルームで早朝から深夜まで業務改革について議論をしていました。
しかしリストラと称して人員が削減され、一方で日々の業務が減らない状況では、プロジェクト活動に終始することは困難となり、今日では現業との兼務のメンバーで構成されることが主流です。
これは極めて大変なことです。
プロジェクト活動では将来について知恵を絞り、職場へ戻れば現実と向き合わなければならないのですから。
残念ながら、頭の切替えが不得意な人はプロジェクト活動においても現状の延長線上で考えてしまいます。
こんな時は、ひと息おいて「よし、今から自分は別人になるんだ」と自分自身に言い聞かせるのが良いのではないでしょうか。

さて、プロジェクトには体制と明確な役割分担が必要となります。
しかし、体制図はあるものの、役割が不明瞭なケースが散見されます。
一般的には下記の様な体制が組まれます(すみません、次回からは図表を貼り付けます)。

    プロジェクトオーナー(経営層、役員クラス)
           ↓
    統括マネージャー(事業部長、部門長クラス)
           ↓                 ←  事務局
    プロジェクトリーダー(部門長クラス)
           ↓
    目的別チーム(複数の場合あり)


さて、上図を見て、皆さんは各担当が具体的にどの様な役割を担うとお考えでしょうか?

うまくプロジェクトを運営できないケースでは、あれもこれもすべてプロジェクトリーダーに仕事が集中してしまいます。
自ら改革テーマを検討し、アウトプットを作成し、チーム毎の進捗チェックを行い、全体のスケジュール管理と課題管理を行い、プロジェクトオーナーや経営層へ活動状況をを報告し・・・と大変です。
結果的にあれもこれも中途半端になり、進行の雲行きが怪しくなってしまういます。
なぜこの様になってしまうのでしょうか?
原因はプロジェクト活動で発生する作業毎に明確な役割分担を設定していないためです。
役割を明確化し、プロジェクト活動が本格的に開始される前に全関係者で役割を確認する場が必要となります。
また、その役割を確実に実行するためにはどの様なスキルや振る舞いが求められるのかも整理しなければなりません。

例えばサプライチェーン改革のプロジェクトを立ち上げることを例とします。
各業務領域~設計、販売、生産、調達、物流、製造などからチーム編成されるとしましょう。
具体的な活動事目としては、
 -各業務領域毎に改革テーマを策定する
 -改革テーマを具体的に構想する
 -現状と改革後の変更点を可視化する
 -改革テーマを実現するための業務の手順と基準を策定する
 -業務領域間の流れに矛盾がないか検証、調整する
 -業務全体を具体的な顧客や製品に基づいて一気通貫に検証、調整する
 -改革後の業務を管理者、実務者へ説明、教育する
 -業務領域毎の進捗を管理する
 -業務領域毎の課題と対策方法を管理する
 -プロジェクト全体の進捗を管理する
 -ヒト、モノ、カネに係わる追加投資に関して経営へ相談、上申する
 -会合の議事録をとる
 -会合に日程管理を行い、開催の通知を行う
 -改革が実現する様に士気が上がらないメンバー達を鼓舞する
 -プロジェクト活動期間中に発生しそうなリスクを洗い出しリスクヘッジの監視をする
 -プロジェクトメンバーからの相談に応じる
など多岐に渡りますね(勿論、上記以外にも山のように作業項目はあります)。
この1つ1つの作業項目を誰が担うのか、どう担うのかを事前に確認・共有します。
事前準備を行わず「走りながら考える」に強く依存すると、どこかで破綻しかけてしまいます。
「そのくらいのことは言わなくてもわかるだろう」ではいけません。
実は言わないからわからない人が意外に多いのです。

作業項目全体を事前に抽出・整理することは活動全体像を俯瞰することにもなり重要な第1歩となります。
最初はそれほど細かな作業項目まで抽出しなくても大丈夫です。
ただし、大項目でヌケ、モレが生じない様な点検は必要です。

さて、上記の作業項目の中でマネージャーが行う項目、リーダーが行う項目は一体どれでしょうか。
多くの企業でリーダーシップとマネジメントの教育をさせて頂いておりますが、両者を混同したり同一視する場合が圧倒的に多いと痛感しています。
マネジメントとは管理・統制すること。組織メンバーが円滑に業務が出来るように環境や制度を整備することです。
一方、リーダーシップとは組織メンバーに働きかけ、動機付けを行い、組織をより良い方向へ向わせることです。
よく私がプロジェクト活動で訴求する事に「一体化」があります。
これは当然、リーダーシップの範疇になります。
しかし、組織の上に立つ職制の人はマネジメントとリーダーシップ双方を発揮しなければなりません。
管理・統制のみでは変革は起きませんし、問題意識・当事者意識・危機意識も起きません。
また、動機付けだけでも事業運営は行えません(ヒト、モノ、カネの予算統制がしっかり行えなければ事業は成り立ちませんよね)。
人材育成を行う際には、マネジメント能力の育成を行うのか、リーダーシップ能力の育成を行うのかを明確化しなければなりません。
そして、教育対象メンバー一人ひとりについて、どちらの能力が高いのか、どちらの能力を高めなければならなのかを把握しなければなりません。
そのためにもこの2つの能力とは何かをぜひ整理して欲しいものです。

今回の例では、予算管理、全体スケジュール管理はプロジェクトマネージャーが担うべきです。
プロジェクトリーダーは各チームのアウトプットレビュー、課題に対して適切な方向付けを行う、今後の活動をどう展開していくのか予測していく、チーム間の調整を行うなどの役割を担うべきでしょう。
チームリーダーがチームメンバーや範疇の職場からのプレッシャーで潰されない様なサポートも重要です。
この点、マネージャーとリーダーの間で事前に話し合っておかなければなりません。

さて、これからプロジェクトを立ち上げる予定の皆さん、あるては既に活動中の皆さん、役割分担は整理されていますか?
名前だけ体制図に入っているけれど役割を遂行していないなんいいうメンバーは一人もいませんよね。
マネージャーとリーダーの役割は大丈夫でしょうか?
マネジメントとリーダーシップ開発のための人材育成は実施されていますか?

みなさん、未来に向って叡智を出しましょう!!
© 未来に向けて考えよう!. all rights reserved.
Page top
FC2 BLOG