議論していきたいテーマ

柳生　謙 (2015年10月 7日 12:47) 11 票 0 票

このトピックの最新投稿のRSS

トピックを書き進めていく過程で
今後議論していきたいテーマを
付箋代わりにメモしていきます。

返信(11)

| 返信する

柳生　謙 | 2015年10月28日 18:30 | 返信

オペレーション

「02.ERPソフトの構成」のところで、

・Order to Cash　（販売業務プロセス）
・Procure to Pay （購買業務プロセス）
・Plan to Product（生産業務プロセス）

について書きました。

業務プロセスはビジネスプロセスとも言います。

業務プロセスを通じて、購買した原材料等に価値が付加されていく。
これがバリューチェーン。

業務プロセスを通じて、原材料等が製品・サービスに変換されていく。
これがオペレーション。

業務プロセスを通じて、顧客に向けて製品・サービスが創造、提供されていく。
これがマーケティング。

三者ともニュアンスは違えど似たもの同士かと。

このフォーラムではオペレーションに注目します。
生産活動との関係が一番深いと考えるからです。

サプライチェーンとエンジニアリングチェーンの合流を検討していくうえで、
全社最適の観点からオペレーションを誰がどう構築していくか、
実務上すごく重要なことと考え、
このフォーラムで議論していきたいところです。

もちろんトピックが発散しないように留意いたします。
中村昌弘 | 2015年10月29日 10:08 | 返信

サプライチェインとエンジニアリングチェインの整合化の考え方について期待しています！
柳生　謙 | 2015年10月29日 12:09 | 返信

中村さん

コメントありがとうございます。

とても重要なポイントを指摘していただきました。

今後の投稿に生かしていきます！
柳生　謙 | 2015年10月30日 16:08 | 返信

製品とサービス

オペレーションで産み出されるプロダクトが製品とサービス。

これがどういう構成であるのか。

これが決まっていないとBOMが作れない。

特に販売BOMが作れないと受注明細が決まらない。

受注明細が決まらないと受注が確定できない。

こういう視点からこのテーマを取り上げてみます。

製品とサービスはIoTともからみますし、

幅広いテーマですが、発散しないように努めます。
柳生　謙 | 2015年10月30日 16:33 | 返信

変更への対応

BOMもひとつの構造。

構造には静的構造と動的構造があります。

静的構造は時間の経過によっても変化しない。

動的構造は時間の経過によって変化する。

ビジネスは変化（変更）がつきもの。

BOMに対して変更を加える場合、それを設計変更と呼びます。

略して設変（せっぺん）と呼ぶこともあります。

英語で表記する場合、EC（Engineering Change）などと呼ばれます。

BOMに対してどういう場合にどういう設計変更があるのか？

その問題点は？

それらを取り上げていこうと思います。
柳生　謙 | 2015年10月30日 16:46 | 返信

どのコードで管理するか

図番、品番、整番などなど、製品を識別するコードは多々あれど、

作業上においても、管理上においても、

個々の業務でバラバラなコードで管理しては、

製品・サービス単位に各プロセスでの状況を追えなくなってしまいます。

業務プロセスを通して一つの番号体系で管理したい。

そしてそのコードが監査証跡のための追跡コードとして使えるか？

BOMに関連して、ここらへんを議論していきたいと思います。
柳生　謙 | 2015年10月31日 13:51 | 返信

生産形態と業務プロセス

生産形態とは製品のつくりかたのことです。

例えば下記のような生産形態があります。

1)受注生産

ETO(Engineer to Order)：個別受注生産
MTO(Make to Order)：繰り返し受注生産

2)受注加工組立生産

ATO(Assemble to Order)：受注組立生産
BTO(Build to Order)：受注加工生産
CTO(Configure to Order)：受注仕様組立生産

3)見込み生産

MTS(Make to Stock)

これらの生産形態により業務プロセスの順序が異なってきます。

同じ会社でも取り扱う製品によりさまざまな生産形態を取ります。
サプライチェーンとエンジニアリングチェーンの合流を図っていく上で
生産形態の違いにどう対処していくかは重要なことと考えます。

そこで本フォーラムでも議題に取り上げたく。
柳生　謙 | 2015年10月31日 14:14 | 返信

実績の収集

現場での作業について工数実績をどう収集していくか。
結構悩ましいところです。

作業管理上でも原価管理上でも工数実績の把握はとても重要。
でも現場での工数実績の記入(or コンピュータ入力)に手間をかけたくない。
実績を入れずに計画のままでは管理にならない。

そこでどういう工夫が考えられるか。
本フォーラムでも議題として取り上げたく。
柳生　謙 | 2015年11月 4日 00:19 | 返信

中小企業とERP

ERPは大企業向けと言われることがあります。

しかし、それは誤解です。

ERPの目的は、

「企業全体を経営資源の有効活用の観点から統合的に管理し、

経営の効率化を図る」ことにあります。

これには大企業も中小企業もありません。

ただし、一般的に言って、

中小企業は大企業ほどIT予算やIT人材を確保できません。

そういう制約を踏まえたうえで、

中小企業がERPをどう活用していけるか、

本フォーラムでも議題として取り上げたく。
柳生　謙 | 2015年11月 4日 00:34 | 返信

なぜシステムにこんなにお金がかかるのか

この問いはよく聞かれます。

これには発注側の要因も受注側の要因もあります。

全業務に回せるIT予算がないとなると、

どうしてもIT化しやすい業務に回しがち。

サプライチェーンとエンジニアリングチェーンの合流を図るためにも、

情報の流れが分断されてしまうことは避けたい。

そこで、まずはシステム費用の高い理由とその対処について、

本フォーラムでも議題として取り上げたく。
柳生　謙 | 2015年11月 4日 00:57 | 返信

上流と下流

業務プロセスにおいても情報システムにおいても
この言葉はよく聞かれます。

下流の様々な問題は上流に起因するところが大なので、
上流の方がより重要であるという認識は一般的にあると思います。

それはその通りなのですが、

ある川の下流は別の川の上流になるケースもあります。

情報システムでいえば、現行のシステム運用(下流)は、
次期システムの企画(上流)につながっていく面もあるのです。

本フォーラムでもサプライチェーンとエンジニアリングチェーンという流れを扱っています。
その際の上流と下流の問題。生産準備の位置づけ。
これらを議題として取り上げたく。