<   2009年 05月 ( 3 )   > この月の画像一覧

ERPとは何か

ERPとは、(元は)Enterprise Resource Planningの略で、製造業における企業全体の資源配分計画の活動を表す概念であった。しかし、今日では、実際には企業の基幹業務範囲を広くカバーする機能を持った統合パッケージ・ビジネスソフトを指す言葉となっている。具体的には、会計・財務・原価・販売・物流・購買などのビジネス系の諸機能をもち、企業の基幹業務範囲を広くカバーすることをターゲットとしている。

「ERP」という言葉をはじめて使ったのは独SAP社であると言われている。この語は、言うまでもないが'60年代に成立したMRP(Material Requirement Planning)から生まれている。MRPは元々、資材所要量計画の略だったが、それが'70年代を通じて発展し、<MRPⅡ>(Manufacturing Resource Planning)という概念になった。MRPは製品の最終需要(独立需要)から、<BOM>(部品表)をさかのぼって各部品・中間部品レベルでの所要量を算出するロジックであった。それがMRPⅡでは資材のみならず、機械・労働者などのリソース、そしてそれらを準備するための購入資金まで、製造業にとって必要な広義の資源の計画ツールに発展した。

ERPとは、さらにその対象範囲を広げた、企業活動全体にとっての資源配分計画の活動である、と位置づけられている。業務パッケージソフトとしても、生産・購買のみならず、会計・販売・物流・在庫管理・倉庫・輸送・品質管理・・とそのカバー領域を広げ、いまやオフィス活動全体をほぼ網羅するようになった。

パッケージソフトのベンダーとしては、今のところドイツのSAP社(この社名はよくサップと呼ばれるが、エス・エー・ピーと発音するのが正しく、そう呼ぶことを知っているかどうかがその道のプロであるかを示す踏み絵みたいになっている)と、米国のオラクル社が二大巨頭である。10年前にはこのほかにもJDEdwadrs, PeopleSoft, BaaNその他有力な企業がいろいろあったが、ほとんどが買収・淘汰され、ビッグ2と、あとは各国ローカルの中小ベンダー、という二極分化の構図が出来上がってしまった。

ところで、「製造業における企業全体の資源配分を計画する」というのは簡単だが、実際には誰が計画するのだろうか? ある意味で“製造業は計画ありきで動く”と言ってもいい。予算があり、販売計画があり、生産計画や配員計画があって工場も営業も動く。しかし、それら複数部門を横断して、全体を統括し計画立案すべき部署は誰なのだろうか。それは、何を基準にして動くべきなのだろうか?

それは、財務部門であるべきだ。--これが、実はERPのテーゼである。そして、その基準としては、『原価』があり、より具体的な手法論としては、活動基準原価管理ABC=Activity-Based Costingを主に用いる、というのがSAP社の思想であった。

これはつまり、言いかえると、会社を支配するのは財務部門である、という考え方である。財務部門から見て、投下するコストに対してリターンを最大化するよう、企業活動を統御すべきであり、コストに引き合わないような活動には資金というResourceは配分すべきではない。はなはだMBA的な思考である。そのために、すべての活動を原価に引き戻すような還元主義的な枠組みが必要になる。このためのツールがERPであり、事実SAP R/3では、FI/COと呼ばれる会計・財務モジュールは必須の中心機能とされたのである。そして、「ERPを入れるなら、まず財務会計から」という合い言葉とともに、多くの企業に普及していったのであった。

しかし現実には、FI(会計)モジュールは使っているが、CO(原価)モジュールを十分使いこなせている企業は日本では少ないと言われている。これは、原価管理が、配賦基準という形の「企業を動かすためのルール・思想」をベースにしているためである。

会計は、ある意味で法律上課せられている義務である。しかし、原価管理はちがう。原価計算報告は求められるだろうが、その結果を経営判断に活かすことまでは法律では定められていない。そもそも、「ちゃんとマネジメントをしろ」などということは、法律にはどこにも書いていないのである。そして、別段プランニングだのマネジメントだのという七面倒なことを考えなくったって、当面企業は動いていくものなのだ。

ということで、残念ながら多くの日本企業では、経営に活かすべき原価基準は(たとえどれだけ財務部門の担当者レベルでは積極的な意見が出されようとも)、思想のないまま決められてしまい、思想のないまま運営され続けるという現実が生じているのである。

また、製造に関して言えば、MRPもまた日本の融通無碍な(いいかえれば計画軽視の)製造現場には四角四面で使いづらい道具であった。したがって、これを活かすとしたら、APSのようなフレキシブルな計画・スケジューリングのツールを補助的に使うことが求められる。

唯一、安心なのは販売・物流系であろうか。たしかに販売系はリベートその他、複雑な商慣習をフォローする必要はあるが、しょせん計画など誰も真面目にとりあわずとも済む業務である。受注トランザクションを、正確に処理してくれればいい、と皆が思っている。データさえ残れば、いつか誰かが分析してくれるだろう。ということで、ERPを作り上げた欧米の人々の高邁な理想とは裏腹に、我が国ではERPは日々の事務処理をつかさどるためのシステムとして使われているのである。

もしもこのような「仏作って魂入れず」の状態を避けて、高価なERP(ビッグ2の製品を全社レベルで導入したら数十億は覚悟すべきだ)を活かしたいと願うなら、何よりも『製造業』の『資源』を『計画する』というのは、具体的にどのような状態を目指しているのか、まず経営者レベルで明確にする必要があるのである。
by Tomoichi_Sato | 2009-05-26 23:36 | ビジネス | Comments(0)

書評:「はじめてのプロジェクトマネジメント」 近藤哲生・著

あるところでプロジェクト・マネジメントの簡単な講義をすることになって、何か参考につかえる本はないだろうかと探してみた結果、手に取ったのが本書であった。PMをテーマにした本は数多い。しかし、抽象的な教科書風の本やITプロジェクトを暗黙の前提としたものはたくさんあるのに対し、新製品開発プロジェクトの事例を、製造業を舞台に描いた本はあまりない。本書はそのわずかな例の一つであり、その意味では貴重かもしれない。

ちなみに、プロジェクト・マネジメントの世界で標準的な教科書のように思われているPMBOK Guideには、ひとつ大きな問題点があると私は考えている。それは、「受注型プロジェクト」と「自発型プロジェクト」の違いを区別していないことだ。というよりも、初期の版のPMBOK Guideは、米国の航空宇宙産業とエンジニアリング産業の人々が中心になって作ったらしく、「最初にスコープありき」でプロジェクトが開始する。その意識は版を重ねるごとに少しずつ薄まってきたが、それでも、最初に「プロジェクト憲章」と「作業範囲記述書(SOW)」のインプットで立ち上げプロセスがはじまり、そのアウトプットとして「スコープ記述書(暫定版)」が作成される、という記述は違和感を感じる人が多い。これは分厚い調達要求書と契約書が客先から渡されてプロジェクトがスタートすることを当然と信じている業種の人間にとってのみ、理解できることだろう。

受注型プロジェクトと、自社がイニシエーターとなって発案し進める自発型プロジェクトは,本質的にちがうものである。前者は行き先が明確に決められており、予算と時間の制約がきつい。後者は進むべき方向があるだけで、到着地点がどこかは定かでない。本書で例として取り上げている新製品開発プロジェクトは、後者の典型例だ。ここでは、『高齢独居者住宅用セキュリティシステム』の開発にチャレンジするセンサー製造開発の企業が舞台になり、ストーリーが進んでいく中で、プロジェクトの進め方の勘所を解説する、という構成になっている。

一般に製造業では、新製品開発には複数の部署がからむ。そうなると、プロジェクト・チームの組織や方向付けや権限関係が悩みのタネになる。複数部署から担当者が任命されて、プロジェクトを進める方式を、ふつう「マトリクス型組織」と言うのだが、これにはプロマネの役割や権限レベルに応じて、いくつかのバリエーションがある。プロマネがとくに指名されないタイプを「弱いマトリクス型組織」という。逆に、PM専門の部署からプロマネがアサインされ、マネジメントに専念するタイプを「強いマトリクス型組織」といい、私の所属するエンジニアリング業界でよく見られる。

ただし製造業での新製品開発の場合、マネジメント専業の人間をおくほどの余裕が無いことが多い。そこで、機能部門からプレイイング・マネージャーがアサインされる。これを、「バランス・マトリクス型」と呼ぶ。もっとも著者はこうした世間一般で使われている用語ではなく、タイプ編成型とかクロスファンクション型とか呼んでいるが、これはまあ言葉の好みの問題だろうからかまわない。

それにしても、私は本書を読んで心底驚いた。何に驚いたかというと、まず最初の章に、

 「『プロジェクトはタコ壺であり骨壺だ。一度入ると生きては戻れない』--こんな感想をよく耳にする」

と書いてある。さらに第2章のストーリーのはじまりには、

 「立ち上げ段階では、集められたメンバー全員が、それぞれの立場で大きな不安を抱えている。過去の経験から、あるいはまわりの状況を見聞きして、『プロジェクトは人をつぶしてしまう、不幸にしてしまう』という固定観念をいだいているからだ」

と解説がつき、さらに追い打ちをかけるように

 「プロジェクトマネージャーが目先の作業をこなし目先の進捗をもとめるだけでは、プロジェクトを支える大きな方針も示せず、リスク対策もできないままに、プロジェクトは無間地獄化していくしかない」

と説明される。ここに至って、あわてて著者略歴を見ると「日立製作所の情報通信部門にて、プロジェクトマネージャーとして数多くの立て直しを経験。2002年に独立して経営コンサルタントとなる」という。“そういう会社だったんだなあ”--思わず、同社の知り合いの人たちの顔を思い浮かべて,考え込んでしまった。

その後も、私には意外の連続である。プロジェクトには、綿密な計画が必要だ、という。当たり前ではないか! テスト工程に入る直前になって、はじめてテスト方法について議論をはじめる。遅すぎないのか? また単体テストの実施率を高める方が工程の品質が上がるという“新発見”もでてくる。検査部門と開発部門とが合格品質基準の有無をめぐって激しく論争する・・どれも、私のように毎日「プロジェクト」でずっと生きてきた者にとって、想像もつかないような状況のパレードである。

ちなみに、本書に出てくるマネジメントのテクニックは、徹頭徹尾、にかかわることだ。モチベーションを上げる、メンバーの成長を促す、幹部を味方につける、問題の解決を皆で喜ぶ・・。一つ一つには、何の異存もない。しかし、ここにはWBS辞書もクリティカル・パスもEVMSもリスク管理表も、いわゆる近代的プロジェクト・コントロールの技法が一切出てこないのだ。理工学的なアプローチはほとんど皆無で、ひたすらヒューマン・ファクターの面のみに指導がいく。日経文庫の「はじめてのプロジェクトマネジメント 」が、これでいいのだろうか。たしかにEVMSだけで新製品開発プロジェクトはマネージできないと、私も思う。しかし、EVMSを知らないのと、知っていて乗り越えるのでは、大きな違いではないか。

本書を読んで、つくづく学んだことがある。それは、組織には2種類あると言うことだ。プロジェクトが“当たり前のこと”である組織と、プロジェクトが“珍しい厄介物”である組織だ。両者では、マネジメントのあり方が質的にちがう。前者では、プロジェクトは家畜である。だから、体重や身長を計量し、毛並みをととのえて、育てようとする。それに対して、後者では、プロジェクトは野獣である。計ることなどとんでもない。踏み倒されずに手なずけられれば、上出来なのだ。そして、日本最大の製造業のOBが書かれた本書を勉強するにつけ、その差をあらためて思い知るのである。
by Tomoichi_Sato | 2009-05-18 23:06 | 書評 | Comments(0)

APSとは何か

MRPの限界を打破した、より現実的で精度の高い生産計画・スケジューリング手法の総称、あるいは、それを実現するためのソフトウェアを指す。厳密な定義はないが、MRPの無限負荷計画よりもリアルで柔軟な制約条件を入れてスケジューリングできるものをAPSとよぶ事が多い。

筆者も理事を務めるNPO法人「ものづくりAPS推進機構」では、『ホワイトペーパー:APSの基本アーキテクチャーとシステム実装技術』(2004年12月)で、APSを次のように定義している。

「APSとは,プランニングやスケジューリングなどの組織の意思決定の要素を統合させ,さらに各部門が組織間や企業間の枠を超えて同期をとりあいながら自律的に全体最適を志向するしくみのことである.APSは,もともと米国にて1990 年代に提案されたコンセプトであり,拡張された詳細スケジューリング技術によって,企業間のサプライチェーンマネジメントを含む,製造業の全体最適化を指向したものであった.」

もっとも、この説明だけでは抽象的でいささかわかりにくい。もう少し今日的な言い方をするならば、APSとはERPのもつ計画機能の弱さを補完するものだ。ERPパッケージを生産管理分野に導入する企業は、APSとよばれる外部モジュールを追加し、両者を組み合わせて使うケースが増えている。ERPパッケージのほとんどはMRPⅡをベースとしたスケジューリング機能を持っているのに、なぜそれだけでは足りないのだろうか?

MRPのスケジューリングは、必要な資材を必要なときに必要な量だけ供給する、ジャスト・イン・タイムのロジックで動く。それは在庫ミニマムのリーン生産を実現する『最適スケジュール』を作成できるはずである。しかしMRPの解は、工場が無限に生産能力をもつことを前提として計算される。つまり、最適であるかもしれないが、実行不可能な絵に描いた餅のスケジュールになるケースが多々あった。

CRPとクローズド・ループMRPを上手に運用すれば、この欠点はある程度解消できるが、それでもまだ深刻な弱点が三つほど残る。

(1)能力以外の制約条件の考慮ができない。
 現実の工場の生産スケジューリングには、多数の制約条件が存在する。たとえば治工具・金型の数の制約とか、中断不可能な作業の存在(複数日にまたがったスケジュールが許されない)とか、設備能力はあっても多能工作業員が足りない、などの制約である。こうしたケースでは標準リードタイムと標準能力の設定だけではうまくモデル化できない。

(2)生産効率の視点からの最適化ができない。
 たとえば、代替部品や代替工程が複数存在する場合に、どちらを選ぶべきかの判断は、MRPでは自動化できない。あるいは、段取り替え作業に順序依存性がある場合(たとえば色の薄いものから濃いものへの切替時間は短いが、その逆は長い、など)に、適当に色の濃さを合わせて、順序づけて流す、などの工夫ができない。MRPにあるのは、在庫ミニマムという最適化だけである。

(3)工程レベルでの納期回答ができない。
 MRPIIでは、MPSとATPによる製品レベルでの納期回答は可能である。しかし、飛び込みや急な変更、資材の遅延などにともなう納期照会に対しては、製造工程レベルで納期を追う必要がある。しかしMRPでは個別ロットと生産オーダーの対応関係(ペギング情報)が保存できないため、精確な納期回答が困難である。

そして、さらに大きな問題として、クローズドループMRPでは計画立案のサイクルタイムが長くなりすぎる点を上げなければならない。市場環境の変化が急速になった今日、週単位で計画をまわしていくことが望まれる。しかしMRP←→CRPの手戻りのため、計画の立案から確定までへたをすると3,4日かかってしまう。

こうした問題点を解決するために、高速かつ柔軟なモデル化能力を備えたAPSが登場したのである。

APSはふつう、ERPなど生産管理の実行系システムから、需要オーダー・在庫量などのデータを各種マスタデータとともにダウンロードする。そしてデータの整合性をチェックした後、スケジューリング計算に用いる。スケジューリングでは、需要オーダーをもとに部品展開をして、優先度とロットまとめを考えながら在庫の引当計算を行ない、個別工程における製造オーダーを作成する。そして着手日の計算と、能力の負荷山積みを行なう。

ここまでの手順は、MRPとよく似ている。ただしAPSでは『タイム・バケットを単位とした標準リードタイム』の考え方をとらず、作業時間を直接、個別に計算する。

 作業時間=製造オーダーの所要量/割りつけた生産資源の処理能力+前後の段取り時間

作業の着手日計算は、納期から逆算するバックワード・スケジューリングで行なう。しかし資材などがネックになる場合は、納入を起点としたフォワード・スケジューリングをする。

この時点で得られているスケジュールは、まだ能力制約を満たしていない。そこでAPSは、高速で自動的に山崩しをして実行可能解を作成する。また代替部品や代替工順などの選定もこの中で行なわれる。このロジックの高速性が、APSの競争力のポイントである。

こうして得られたスケジュールを、APSはガント・チャートなどの形で計画者に対し出力表示する。スケジュールは、必ず人間の目で評価しなければならない。納期遅れが生じている場合、どれを優先し、どれを後回しにすべきか、あるいは加工外注でしのげるかなど、判断を機械まかせにすべきでない事柄が残っているからである。そして、GUIによって手で修正したり、あるいは条件を変えてケーススタディを行なったりといった作業を経て、はじめてスケジュールが確定する。

確定スケジュールは、製造部門に対して開示され、直近に着手すべき製造オーダーがディスパッチされる(つまり製造指図が差し立てられる)。そして、スケジュールファイルとして保存され、納期回答や次回のスケジュール立案のベースとして、利用されるのである。

ものづくりAPS推進機構のホワイトペーパーでは、APSの主要な要素技術として以下の事項をあげている。
・作業中心のBOMデータ管理(内部に工順を持つ)
・生産現場の詳細なモデリング
・有限能力&有限資材スケジューリング
・ボトルネック指向スケジューリング
・MPS詳細シミュレーション
・ダイナミック・フルペギング
・メタヒューリスティックによる最適化

これらは、どちらかというと内部機能的な観点のリストである。私は、これとは別に、「APS導入を考えるユーザがベンダーに聞くべき10の質問」として、以下の問いをあげたいと考えている。

(1)この製品は生産計画もできますか、それともスケジューラ機能だけですか
(2)この製品はBTOに対応できますか
(3)この製品は複数工場のスケジューリングができますか
(4)BOMの切替えや代替にはどのように対応しますか
(5)リソースにはどんな種類がありますか
(6)工順や設備・ライン・作業の選択は、どのような判断基準で行いますか
(7)ローリング・スケジュールのタイム・フェンスはどう設定できますか
(8)リモート・バッチで納期照会が可能ですか
(9)MESから進捗情報をとりこむ機能がありますか
(10)最適化機能のチューニング・ツールはそろっていますか?

念のためいうが、これらすべてが必須項目だという訳ではない。ただ、これらの質問に、ベンダーが的確に答えられなかったら、ちょっと心配だから誰かコンサルタントに相談されるといいと思う。そして、これらの質問の意味がユーザ側にとって半分以上わからなかったら・・もしかしたら、まだAPSの導入は早すぎるのかもしれない。
by Tomoichi_Sato | 2009-05-07 22:35 | サプライチェーン | Comments(0)