生産管理ソフトはどうしています？
製品点数は、約３千件。
Accessの知識が少しあるばかりに、「生産管理ソフトを作れ！」
といわれました。
なんか参考になるソフトはないでしょうか。
ちなみに現状は、ExcelとWordを使って納期管理だけをしていま
す。
納期管理だけではダメでしょう、と発言したら、
「だったら、おまえが生産管理ソフトを作れ！」
となってしまいました。
納期管理の他、在庫数や、職員の作業時間の管理なんかも考えな
ければなりません。
この正月がユーウツです。
次に部品あるいは工程順序に関係付けされた標準時間がそろっているか？
なければこれを作ることからスタートだ。
これがないとパッケージ製品を導入するにしても自作するにしても
納期の基準がないわけだから話にならん。
在庫管理が必要なら部品ごとの在庫表を作れ。
これらはAccessでもOKなんだが、
おそらく多くの端末から在庫更新することになるので
Accessで普通に作っただけだとだとめちゃくちゃ壊れやすい。
VBAがわかるなら「非連結フォーム」をつかって作ることを強く勧める。
少しは堅牢なサーバがあるならMSDEとadpでつくっとけ。
その後、パッケージ製品を導入するならパッケージ屋に、
そうでなければここでさらに煮詰めよう。
いずれも単純でどこにでもある表構成にしておこう。
難しくしてしまうと後々パッケージ製品を導入するときに無駄なカスタムが入ってしまうからな。
で、進捗状況はどうよ？
とりあえず、Access2000で、次のテーブルを作り始めました。
製品マスター 約3000件
材料マスター 約200件
外注マスター 約100社
レコードは年明けに、事務の人に入力してもらおうと思っています。
製造課長に聞いたところ、１つの製品に関係する部品が、最低で５件、
最高で70件ぐらいあるそうです。
ひょっとして製品マスターと部品表を組み合わせたら、レコードが数万件
になるのか？ と卒倒しそうになりました。
MSDEにまで手を出すのは億劫なので、できればAccess2000で済ませられれ
ばと考えています。
標準時間は、いままでまったく把握していません。
納期に間に合えばいいという会社ですので。
製造課長の直感によると、当社製品の半分は採算割れじゃないかと。
それでも、何とかやってこれたのは、独自の技術があるからだ、と笑って
いました。
経費節減の折、システム開発を外部に委託するのは無理みたいです。
経理担当として入社したのに、なんでまたこんなことをせにゃならぬのかと、
再びユーウツになりました。
追加で質問なのですが、Aceessだけだと、やはり壊れやすいんでしょ
うか？
前にいた会社で、30人程度の時間管理表をAccessだけで作ったことが
ありました。
一度に複数の人が入力しようとすると、スピードが落ちるというクレ
ームはありましたが、10万件のレコード蓄積でも壊れたことはありま
せんでした。
ただし、いま現在、その会社がどうなっているかはわかりませんが。
とはいってもソリューション屋でも経理屋でも管理屋でもないんだけどね。
【AccessのMDB】
行ロックをサポートしてないおかげで更新が多いとほかの人が作ったデータが良く壊れる。
エラーも出ないから結構気づかないんだよな。
ページロックでデータが壊れる仕組みはわかるよね？
Accessで複数人数が叩くデーブルは非連結で作るのが基本。
-----------------------------
本題。
最初にいっとくことだと思うけど、経理屋さんが生産管理まで面倒見るのって大変だと思うれす。
社長とか製造管理担当の強い協力なしだとかなり苦労しそうｗ
出来上がるものが楽しみ♪
【サンプル】
最近Googleと日経メカニカルで生産管理系のソフトを探したけど実際のところ
パッケージの高額な製品しかでてこなくて辟易したですよ。
画面サンプルもソリューション製品なんでほとんど見せてくれませんです。
市販のDB(Access)の教科書も販売システム系はよくサンプルがあるけど
生産系はめったと見かけないのでむしろ「生産管理概論」とかの教科書から
仕組みだけを読み取って自分でアレンジしてもいいかと。
ちなみにうちは社員数百人規模なのにメインフレームでやってる部門と
C/Sでやってる部門とAccessでやってる部門とに分かれてて統制が取れてない。
まあ動いてるから良しでやってる。
おかげでサンプルには困らないｗ
専門外なのでパス。むしろ経理屋さんの方が詳しいだろうと。
たしか販売系システムのサンプルがAccessの本にあったと思うのでそっちをみませう。
【納期管理・作業時間】
ST(標準時間)なしでどうやって納期とか作業時間管理するんじゃボケェッ！！
とかいいたくなるのはうちが製造系メーカーだからとかそんなツマンナイ理由なんだろうな・・・。
え～と。
あたしの想像では部品屋ってことはひとつの製品あたりのサイズとかロットあたりの
生産期間・規模が大きくないと思う（ラインじゃなくて屋台でしょ？）ので
工順マスタにSTを組み込む必要はなくて製品マスタにSTを込むだけでも十分かもしれないれす。
とりあえず製造担当者にお願いして半年くらいロットごとの予想時間と実績時間を
現行の生産予定表なんかに書き出してもらうと良いです。
（実績時間だと不良修正とかのノイズが入りやすいので両方が無理なら予想時間の方がいい。
この辺の話題はS/N比とか統計手法とか行動心理学とかの話で面白いけど割愛）
集まったデータは全部溜め込んで製品ST=Σロットにかかった時間/Σ生産個数
にすれば、半年くらいで管理屋が使うには十分な精度のデータになるです。
経理屋ならわかってると思うけど、最初から過剰品質のデータを得ようとすることはやめませう。
標準時間は生産管理の教科書を見るとストップヲチとかかなり面倒くさい方法が載っているけど
会社の余力がないならやめておくのが吉。
最初の間は現場の勘を全面的に信頼して「経験見積もり」に徹して、早く多くの製品の
データをそろえるようにしたほうがイイ。
そうしておけば精度に不満が出てきたときも現場が自分たちで何とかするからね。
であ。
http://www.agemasukudasai.com/bloom/
こんろはお酒の無い状態でけきまふ。
ねる。であまたそのうち。
書店で管理システム構築用の本を何冊か買ってきました。
（もちろん会社の経費で）
まだパラパラとめくっただけですが、いずれも生産管理システム向け
とはいえないようです。
ただし、MSDEのところは使えるかも。
桐のものも探してみたのですが、残念ながら見つかりませんでした。
（地方の書店なので置いてないのかも）
一応、簿記１級の資格があるので、活動基準原価計算まで組み立て
られたらいいなと考えているのですが、標準の作業時間さえ把握さ
れていない現状では無理のようです。
製造課長からは「当社は試作品や金型造りが多いから、標準時間と
いわれてもねぇ」と、素っ気なくいわれてしまいました。
システム構築を請け負うベンダそれぞれならのノウハウに属する部分もあるので、
書籍などで一般向けに公開されてる情報は少ないでしょうね。
製造課長の言葉は、今までそうだったのはしかたないけど、DBをベースにこれから
各試作に要した時間を記録していく気もないとしたら、会社として危ないかも
しれません。
> 各試作に要した時間を記録していく気もないとしたら、会社として危ないかも
> しれません。
まったくご指摘の通りです！
営業利益段階で毎期30～40％程度を確保していて、銀行からは超優良企業
とおだてられているせいか、コスト意識が全然ないのです。
決算を締めた後で、「今年も、よくできました。ご苦労さん」で終わって
しまっているのです。
受注案件ごとの能率の良否や損益がまったくわからない状態です。
今年は無借金経営を達成したので、来年はいよいよ生産管理システムだと
腹を決めています。
だいぶ前（２５年前かな？）に「生産管理とは」というのも、今のあなたと同じく追い回していました。
その中に、「管理であるから、予定と現実のズレをチッックして事前に予測を出し、対策するのが目的」
というのを見つけて「金型屋でどうするのだ？」と随分と迷いました。
多くの生産管理の本（とソフト）は、標準工数を設定できている、という前提から始まりますが、金型などでは各社で作り方が違うから「世間の標準工数」なんてものは、無いだろうというのは直感でも分かります。
それで、結局私は過去の実績を元に、経営的な目標を扱い重量に変換しました。
つまり工数は重量に比例すると見たわけです（実績調査からは合っていた）
加工方法を検討すると、金型では加工体積に工数が比例する工程と加工面積に工数が比例する工程があると判断して、図面から加工工数を割り出し、ガントチャート化したグラフを作ったものです。
参考にして下さい。
重量への変換と、ガントチャート！
むむむ、これはすごいアドバイスです。
ありがとうございます。
早速、検討してみます。
正月早々生産管理システムか。おめでてーな。(ｵﾚﾓﾅｰ)
>>1なんて
>まったくご指摘の通りです！
>腹を決めています。
とかレス返してんの。もう見てらんない。
てーか生産管理システム以前の会社っぽいな。お前んところって。
なんか「生産管理システム」って言う言葉に振り回されて
いきなり教科書全体に対して一気に手をつけようとしてるように見えるんだよな。
一昨日も言ったけど、一人で面倒見るにはあまりにも広大な分野なんだよ。生産管理ってのは。
(だからSCMとかISO9000のコンサルがこれだけ流行る）
生産管理のどの分野を解決をしたいのか決めて、現状と問題をしっかり把握し
たほうがいいとおもうぞ。
わかってる限りでは在庫管理・納期管理・工数管理。
そして最終的には「適正な利益をえるための工数見積もりシステム」と見ているが。
でも、ここまで見た限りだと対策にすぐ着手できるところって在庫管理くらい。
だいたいなんだよ、「そのすごいアドバイスです」ってのは？
ノウハウがロジック化できてない時点でシステム化以前の問題だろーが。
そもそも数値化できてないところにコンピュータの絡むロジックが適用できるかってーの。
だいたい、ワンオフ製品の工数なんぞ現場を信用するところでおまえがでしゃばるところじゃない。
そっけない製造課長でも、なんかしら「図面を見た瞬間の直感」みたいなもんを持ってるもんだ。
その経験や直感を吸い上げてロジック化してやるならともかくおまえが責任もっていいのか？
だいたいおまえの仕事は経理屋だろーが。
工場に立たない経理屋が「製造課長。日程と工数くらい出してくださいよ」ならともかく
「あなたの仕事はこの式で算出します」なんていっていいのか？お前んところは？
得意げな顔して何が、生産管理システム、だ。
おまえは本当に生産管理システムしたいのかと小一時間（以下略。
俺から言わせてもらえば、今、金の無い中小規模の生産管理システムの最新流行はやっぱり、
「任せられるところは現場に任せ、PC化にこだわらず分業で全体を構築」、これだね。
「欲張らずに問題を把握できたところから単機能プログラムと帳票(紙)をつくって運用でシステム化」
システムといっても全機能がひとつのソフトだったりデータを共有する必要はない。
適材適所。場合や規模によっては紙ベースのほうが運用しやすいかもしれない。
帳票が十分成功してからPC化しても良いし、目に見える帳票はISO-9000化を
目指すときにも非常にわかりやすい。
そもそも帳票を直すのは簡単でもロジックを直すのは大変なんだよ。
本題。
【在庫管理】
多品種を扱う企業として必須業務だし無いということが問題だ。作れ。
この業務に関しては会社ごとの独自性が入り込む余地なんて分析機能以外ほとんど無い。
製品・材料マスター管理、仕入れ先マスター管理、入出庫管理、伝票印刷、棚卸、在庫分析etc.....。
せっかく今作ろうとしてるんだから完成させろ。
【納期・工数・工期管理】
問題があることがわかっていてもどの程度問題が潜んでいるのかわかってない様に見える。
こっちも部品屋と聞いて大量生産部品と思ったから標準時間の話し出したけど
ワンオフ（試作や金型）の比重が大きく少量短期生産だと標準時間だけでの管理は無理。
でも標準時間だけの管理ががだめならそれはそれでやりようなんていくらでもある。
業務管理ができてないなら（社長命令で）製造課長に業務予定と実績つけさせるところからはじめろ。
手書きでもプロジェクト管理ソフトでもいい。まず製品ごとの予定と進捗と達成率を報告させろ。
で、実績工数を営業の売り値で付き合わせると社長の顔が・・・・（l||ﾟдﾟ）・・・・ってことになるから。
規模によってはMicrosoftProjectと発表用のPC用プロジェクタ導入するだけでOKってことだってあるしな。
（あ～～他人事だと思うといいたいこと言えてイイワ。）
生産現場を知らない人の作った生産管理システムなんて現場ぢゃ見向きもされない。
頑張って下さい。
とりあえず、生産管理システムとかいう大きなものまでは考えない方が良いのではないでしょうか。
一人で抱え込むにはあまりにも大きすぎる気がします。
まずはＭＳＤＥをセットアップして、部品（材料）と製品の出入りにかかわるデータをきちんと取り込み、共有できる環境を構築することからやるのが吉かと。
多分、それをやるだけでも様々な問題が顕在化すると思います。
ちなみに私がそういうことをやったときには、お爺ちゃん連中の保有する『脳内仕様書』の数の多さに泣きそうになったことがありました・・・
なにはともあれ、ガンガレ！
>>1がどれだけ恥と情熱をさらせるかがこのスレのポイント。
がんがれ！
『脳内仕様書』・・・わかるなぁ。
お爺ちゃん連中に限らないよ。
他人事な連中は、ああだこうだと頭の中だけでいろいろな可能性を妄想して、
「それら全部に対応できる実装を」と要求したがるものだ。
若い連中はそれほど経験がなかったり表現能力がなかったりして、要求が増えないだけ。
お爺ちゃん連中は年の功で経験が一杯あるから、思い浮かぶ可能性がいろいろあるだけ。
若い連中でも、変に知識ある奴はああだこうだと言うものさ。
それらの要求を受け流しながら、つきつめればどこが要点なのかを分析して、
単純な構造に還元するのが、こうしたシステム構築の勘所だね。
１人でやるようなら、一番の要点を見つけて、そこから積み重ねていくのがいい。
頑張って欲しい。
http://freeweb2.kakiko.com/dengeki/index2.htm
数多くのご発言、ありがとうございます。
この１年、取り組んできたことは――
●売上高から直接原価（直接費ではありません）を控除した製造限界利益（限界利益で
はありません）までを、製品別に求めるところまでできました。
これにより直接原価計算方式の損益計算書を作成することができました。
ただし、これらはExcelででしか作成できないことが不満足でした。
●いまの会計ソフトは部門別課別に入力することが可能なので、部門別直接費・部門別
間接費と全社共通費とにそれぞれ区別して把握することができるようになりました。
就業時間を短期予定操業度とすることで、部門別の間接費配賦率を最小自乗法で求める
ところまでできました。
ただし、部門別間接費を製品別に予定配賦するまでは至りませんでした。
これは、予定配賦の前提となる、作業時間の管理ができていなかったためです。当社の
最大の弱点です。
●作業時間の管理にあたっては、工程別原価計算のコストセンターか、活動基準原価計
算のコストドライバーのいずれかを設定することから検討するつもりです。
作業時間だけでなく、機械加工時間も把握したいところですが、最初から多くを求める
のは無理だと考えています。
やはり脳内仕様書が最大の壁でしょうか。
●在庫管理は前期から、ＡＢＣ分析に基づき、日次棚卸・四半期棚卸・期末棚卸を実施
しています。
在庫には予定価格を適用し、受入価格差異を把握するようにしていますが、Excelによる
管理だったので、これをデータベース化したいと考えています。
今期中は税法の届け出による評価方法（最終仕入原価法）によらざるを得ないので、予
定価格を採用した在庫管理の本格稼働は、税務署への届け出後の来期以降になります。
それと、ストックオプションを持っているので、従業員に対しては、潜在的な株主とし
て発言できるのが個人的な強みです。
少しずつ、Accessで組み立てているところです。
現在、検討しているのは、次のような事項です。
●部門別間接費を製品別（またはプロジェクト別）に配賦する基準は、作業時間以外に
どのようなものがあるか。特に部門別計算において。
機械加工時間を把握するには、どのような方法があるか。
ただし、これらは活動基準原価計算によらない場合。
●活動基準原価計算による場合、コストドライバーを設定する基準はどのようにしたら
よいか。
●期中は工程別原価計算を行い、期末だけ売価還元法計算によれば、決算作業は随分と
楽になるのではないか。
●研究開発活動について、予算管理や時間管理以外に有効な統制システムはあるか。
●ガントチャートを作業日報として転用して入力する画面構成など。
経営版のほうがよくないかしら
まさかAccessで自作する気でわ？？？
死ぬぞ。
Projectにしとけ。
参考にするのがいいのでは？
そのまま使えなくとも、かなり勉強になりますよ。
個人的にはプログラムはVBで作ったほうがいいと思います。
ST計測とか工程直行率管理とかのことだったらアレは自分で使うための道具として作ってないと思う。
ST計測の方はそもそもAccessで作ってる事が間違っている。機能も片手落ちすぎ。
少なくともビデオ分析で使えるツールじゃないのでExcelでsec→dm変換する関数作って帳票から自作した。
（うちの場合STはビデオ観測、KKD、これらを元にした標準資料のいずれかでSTは「ST式」として管理)
直行率管理は使いようによっては何とか。
でも業務とか会社の形態(用語)に依存する部分がカスタマイズできなかったのでこの業務も自作した。
Excel工程表とかは論外。（図形オブジェクトと数値がリンクしないのでただのお絵かきソフトにしかならない）
①解決すべき問題は何？
②そのために管理されるべきなのは何？
③それを管理するために用意すべきなのは何？
特注ホワイトボードだったり帳票整理棚だったりしないか？
#個人的にはAutoCAD+ObjectARXによる泥縄が好みなんだけどね。
#OLEのネストで死ぬ。
経理屋さんがAutocadで生産管理・・・・萌えっ！！
オーバースペック(場違い）ッぷり素敵過ぎますゥ・・・ﾊｧﾊｧ♥
（↑会社が買ってくれなかったのであてつけにCADAMで製品仕様書(80P)をDTPしちゃった人。）
でああそびにいってきまつ。
タイトルと内容が矛盾しています。
また、１さんが原価計算の話をしているのに、レスのほとんどが、生産管理でもなく原価計算でもなく「システム」に集中しているのも不思議。
現場を知らない経理屋と、原価計算理論を知らないシステム屋の競合では、議論にならないのでは？
１さんは、岡本清先生の「原価計算・六訂版」を読んでいるものと推察。
標準原価計算と、その先にある原価企画の構築から始めるのがよろしいかと。
部門ごとの間接費配賦率を求めるところまで到達しているのであれば、工程別原価計算がいいかもしれません。
コストセンターごとの配賦基準は、直接作業時間によろうと機械加工時間によろうと、部門別計算の段階で設定すればいいと思います。
活動基準原価計算におけるコストドライバーは、作業日報を実際に入力する段階で様々な問題点が吹き出すので注意したほうがいいですよ。
なんつーか、事務屋の事務屋による事務屋のためのマスタベーション臭いんだよな～。
（煽る気は無い。）だから皆横に少しずらしてるんだと思うよ。
ちなみに俺は原価計算関連知らない。うちはドンブリの借金だらけ。
で、どこがどういうふうに臭いのかAさんの会社での例を。
/****************
Aさんの会社は部材展開を把握していない。部材展開できないってことは
適正在庫を把握できないってことで、管理しようにも管理基準が作れない。（まあ業種によると思うが。）
でも、日次棚卸はやってる。綺麗なExcelの表で毎日だって出力できちゃう。
で、Aさんは欠品が出たるとこう思っちゃう。
「現場は馬鹿だ。これだけちゃんとした在庫管理をやっているのに、それを活用しようとしない。
Oracle入れて現場にIT端末を置いて、さらに情報の浸透を図るのが進むべき管理の理想だ。」
ﾌﾟ。いくら金をかけても欠品は無くならず、脳死状態のシステムと入力する手間だけが増殖していく。
でもAさんは自分の仕事をちゃんとやってるように見えるから怒られない。
実はAさんがやっているのは在庫数把握で在庫管理は誰もやってない。
でも組織が未熟なので誰も気づかない。
*****************/
こんなふうに臭い。管理が進めば出てくる帳票類を会社から搾り出しても、管理は進まない。
ちなみに昔読んだ御本を久々に開いてみると、生産管理システムに絡むサブシステムとしては
部品情報管理、工程情報管理、生産計画、所要量計算、工程管理、工程実績管理、在庫管理、
購買・外注管理、販売管理があって、原価計算システムに関るシステムとしては、
在庫管理システム、財務会計システム、生産管理システム、管理会計システムがある、とか書いてある。もう意味不明。
50人規模の会社でどこまでやるのか知らないが、全部まともに叩き込もうとすればほぼ確実にRる。
参考文献：中央経済社「生産・在庫管理システムの設計」ISBN4-502-21284-9 C3034 \4000E
↑：見てみたらこの本シリーズで全5巻でてるぞオイ。先長すぎ。
業務をパッケージに合わせる
パッケージ導入よりは安くつくんじゃないかなぁ。どうなんだろ？
http://www.as-net.com/free01/mkgif/mkgif.cgi?osaka
http://res9.7777.net/bbs/osakaband/
http://www.benricgi.com/bbs/vr/d/130211/osaka.htm
たしかに経理などはそれでもいいが、
生産になるとノウハウになるので難しい
43は極論だが、生産側を変えずにシステム化するのは不可能に近い。
パッケージといっても限界があるさ。
だからといって、独自に作るのも難しい。
生産管理システムといえば、独ＳＡＰ社のＲ／３がトップシェアといわれているけれど、導入後の失敗事例が多くあると聞く。
ＳＡＰに毎年１億円以上の費用を払いながら失敗するんじゃ、たまったもんじゃないね。
かといっていつまでも旧態の方式（脳内仕様や紙記録）ってわけにもいかない。
事業拡張したら、どこかで効率改善が必要になる。多くの場合、コンピュータ化になるけど。
建前は成功しますと言うしかないだろうけど、ある程度の失敗や損失は覚悟して
おくものなんじゃないの。
まともな会社ならそれを飲み込む余裕はあると思うし。その余裕も許されないくらい
追い詰められてる所は、そこまで事態を放置していたことに問題があるんだけどね。
たくさんの書き込みありがとうございます。
正月休みを利用して、スキー旅行に行っていました。
進捗状況と、さらなる相談は改めて行います。
現場の手法をまったく変えずにシステム化する場合、
例外なく失敗する。
かといってパッケージですむほど単純じゃない。
だから生産管理システムなんてのはベラボーに高いのです。
膨大なカスタマイズが必要だから。
偉い人にはこれがわからんのです。
とりあえず桐でも使って身近な所から組んでみよう。
桐なら柔軟に仕様の変更に答えられるし、一人でも作っていける生産性を持っている。
また多少正規化を犠牲にしてもよい汎用性もある。
間違ってもアクセスなんかでやらない方がいい。度重なる仕様変更で正規化が
崩壊し、帳票出力で要求に応えられず、泥沼に絶対ハマる。１００％はまる。
そして使えないシステムとして烙印を押され消えゆくだけ。
＞度重なる仕様変更で正規化が崩壊し、帳票出力で要求に応えられず
現実味に溢れてるな。苦笑いがとまらんぞ。
MSDEを使うのではなく、Accessの「データアクセスページ」を使うのって、やはり負荷（またはリスク）が大きいのでしょうか。
なお、イントラネット環境で、同時アクセスが５名以内でデータアクセスページを利用する条件下ですが。
なぜに桐？Accessも桐も大差ないだろう。
なすべき事はデータベースとプログラムを分離する事ではないのか？
桐も命脈は尽きたといえるだろう
生産管理で開発ツールを選ぶのはもっと後の段階だろ。
先にツールを選んでどうする。
紙で計算合わない事やってる事はＰＣにはのらない。
紙は便利だから、一行にむりやり二個書き込んだり、合計値をつじつま合わせて
書き換えてしまったり。
ＰＣは万能ツールではなく、人が本来行う処理を簡略化するだけ。
まずは業務を見直して一貫したルールで動いているか、例外的な処理
が多いのかどうか？手書き時代の習慣にいつまでもこだわっているかどうか。
小ロット多品種生産で、仕掛品とか外注加工品まで管理
すると、入力する手間が増えて、忙しいときに役にたたない。
http://www5b.biglobe.ne.jp/~ryo-kyo/osu.html
▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲▼▲
( つか、現場の声に聞こえるな、両名の発言は)
定型化しないとコンピュータ化は無理だし、
管理対象(完成品とその材料)の管理(マスター化)が出来ないと
生産管理は無理。
生産管理から原価管理まで行くと、見積－受注－(材料)発注－加工計画－納品計画(検収)
んで、これに並行して 仕入・支払管理、勤怠管理(作業日報)、請求・入金管理が
入る(見積、仕入、加工、納入、請求、入金)。
ここまでいってやっと、「今回の物件は単独で儲かったのか？ どうなのか？」
が判る。
ただ、A物件の部材・部品を納期の兼ね合いから急遽B物件に回して、遅れて
入った部材・部品をA物件に戻すなんてのは茶飯事だろうから、そういう付けかえ
も必要となる。しかもこゆのは製造部門が勝手にやったりすることもある(w。
まずは「紙」ベースで起こすことだな。
漏れ、昔そういった業務・要件整理だけ請け負ったことがあったが、数百万
掛かったぞ。それでも「安く済んで良かった」って喜んで貰えたがな（ｗ
ちなみにユーザー規模は多分 >>1 ん所の数倍。
でも、業務内容は近そうだから、多分同じくらい大変だ(部門間の調整とか)。
がんがれ！
全ての(見たい)業務フローと言うことです。
他人が立てたスレだが、いろいろと参考になるなあ
肝心の部分が頭から消える｡まあ、自動記録装置くらいに考えたほうが無難。
下請けの製造やってるのなら、時間軸をＰＣに管理させないこと。
生産計画があって計画的に製造している会社と同じシステム使ったら、
会社潰れるよ。
ひょっとしたら良スレ？とかも思ったわけだが、
70ちょっとで終わりとは・・・
忙しいときは「丸投げ」したりする場合、どう管理するのでしょう。
ノートにボールペンで書いておく。
外注管理というか、発注管理が必要かな。
発注＝仕入の場合は、まんまだが、
発注＝外注の場合は、発注内容(加工内容)と加工工賃、見積価格と発注価格の
管理が必要かな？＞原価管理
資材部は、部品・部材が外注調達なのか納品なのかが鍵。
外部調達は丸投げ、納品の場合は諸々の手続き発生の可能性大。
部品・部材納期が遅れた場合の保証など＞入手元の責任
つか、このスレは年度末(発注のとぎれ発生)で、終演か？
春先など、製造関連は閑古鳥だし、あと２ヶ月ちょいの命かな（ｗ
すべての経路を網羅したマスタを作ったと仮定しても、
仕掛投入時に、どのマスタで作業するのかが未定であれば、
管理は不可能でしょうね。
適当に（マスタを）選んで進行しても、途中で分岐したら、
おしまい・・・ですね。製造は難しいですよ。
ここで儲けて、宝くじ買おう。
とか言う人を（会社を）いくつか見ましたけど・・・どうなんでしょうねぇ
(>>76さんがそうだとかいうことじゃないんですけど)日々の受注をこなすことしか考えていなくて、自分のやっている仕事の見直しなんかしたことのないような人って意外と多い気がしますが・・・
ひどい時には、自分の作っている物の工数さえ把握していなかった製造業の管理職を見たこともあるですよ。
ところで>>73さんは何を管理したいんだべ？
在庫管理にしても原価を把握するためのものであって、適正な在庫や発注タイミングなど
まるで興味無し。まぁ経理屋が考える生産管理システムなんて所詮こんなもんだよ。
正直に原価計算システムって言えばいいのに。。。
ところで1の会社は部材発注数とかどうやって計算してるの？ 試作だったら受注毎に図面の
部品表を見てで、金型だったら体積分の鋼材をどんと仕入れておけばいいくらいか。
おっと、こんなことはどうでもいいことだよね！ 部品表で卒倒するくらだから。w
色々大変だと思うけど頑張れや！
大企業は参考にならない。周囲が必死で合わすから。
工順マスタを編集するエディタを作成、あるいは導入しようとしています。
工順マスタを効率よく編集するシステムというのはなかなか見当たらないのです。
最終的に「QC工程表」と「工程別ST」を一括編集、管理したいのですが
お勧めの既存パッケージはありますか？
※帳票の印刷時には少なくとも次のような項目が必要です。
<ヘッダ>
部品番号、文書番号、作成者、作成日、検図担当者、検図日、
<本体>
順序番号、工程名、付随ST、主作業ST、加工ST、
管理項目(0..n)、管理水準(0..n)、管理方法(0..n)、管理担当(0..n)
※さらに内部的にひと工程ごとに工場コード、加工区コード、所要人数
が欲しいです。
※さらに工程名ひとつに対し、複数の管理項目（作業条件）セットが
必要になる場合があります。
たとえば「塗装」という言葉に対し、筆塗りの場合と、エアガンで
塗る場合では、筆の種類や、筆の使い方が管理項目になると思いますが、
エアガンではエアガンの目盛りや型紙が管理項目になります。
※最終的には管理水準の値を元にSTの自動計算をさせようとしています。
今日、たまたま本屋さんでみつけた
「生産管理・原価管理システムのためのデータモデリング」
という教科書を見つけたので買ってきました。
ちょうどこの本の第2部1章の「工程表」が私の欲しい対象のシステムになります。
これ以外は考慮の対象にはなりますが、開発の対象になりません。
（部品表はすでに存在していますが、加工が主なのでこれと密接に結びつく必要はないです。）
本は言葉の表現が私の会社と違っていて少し引っかかりますが、
参考になりそうなギミックも載っているので薄くて安い本の割には使えそうです。
８３を書きながら気に掛かっていた「子レベル部品の処理」も解決の糸口がつかめそうです。
-----
実を言うと上の教科書のことはイそこそこにメージどおりだったので
比較的安心したというのが本音です。
おそらくここまではどのプログラム屋さんでも同じモノができそうな気がします。
しかし、このエディタを使用する人の苦労は実際のところ、
管理水準の編集(参考書で「作業記述」とかかれている部分）や
STの計算にあったりするのです。
そんなわけで、ここがおろそかなシステムですと
工程設計者に余分な負荷をかけることになります。
このため懸案事項・・・というかシステムを特徴付けるポイントは
1.大量になる品質管理水準の効率的な編集。
2.列項目のスマートなハンドリング。
3.「ST計算のロジックをエンドユーザにメンテナンスさせる仕組み」をいかに提供するか
といったところにおきたいと思います。
http://homepage3.nifty.com/digikei/ten.html
なんかさ、生産管理論のレポートでも提出すんの？
そんなのいくら勉強したって現場では使い物にならないし、
誰も見ないよ。
>誰も見ないよ。
わたしの会社も新しい概念やシステムが導入されそうになるたびに
独自技術にこだわる職人さんや年寄りが似たようなことを言っています。
っていうか、工程マスターは事務屋の計算のためであって、現場の作業者
には必要ないよ。 そのデータを見てどうしろっていうのか？
現場で役に立つ事は歩留まり率の改善や自動化などであって、原価計算は
経理のお仕事。みな役割分担があるのだよ。
まだISO9000シリーズを取得していないのならそれが先だね。
図面管理や不良発生時のトレーサビリティなんて、経理にはどうでも
いいことだよね！ 部署によって観点が違うということを理解すべき。
ん？ >>88でなくて>>89でいいの？
俺は>>88の「新しい概念やシステムvsジジイ」の部分に同意したのであって
その部分は>>90とも対立するものではないと思う。
とはいえ、横から割り込んで>>90に不愉快な思いをさせたのであれば
誤ります。スマン。 m(_ _)m
>>90
>工程マスタは事務屋の計算の・・・・
技術部門で私と同僚が使うためのものと考えてください。
具体的には工程設計をする技術部門が工程の方法と品質とコストを設計するために使用します。
品質と工程を作りこむのは事務屋でも製造現場でもないというのが私の見方です。
少なくとも事務屋が欲しがるような工程マスタエディタは技術部門には必要ないです。
その工程データから汁を吸うのは管理部門であり製造部門かもしれませんが、私は
ひと製品分の工程データを入力→品質とコストが予算に収まるかを検討
のサイクルを最短で行うことができ、工程条件と品質が確実に現場に伝われば、
あとの機能なんてどうでもいいと思っています。
事務屋がそのデータをどう使うかなんて（意識の中にはあっても）知ったことではないです。
現状「Excelで運用しているいる工程表」がすでに「紙の情報として」運用されています。
これを社内データとしての価値、再利用性を高めるため、「DBをバックエンドにした工程表」に
移行させようとしています。そのための「妄想」と思ってもらってもいいです。
一応自作の場合、バックエンドはSQLServerかORACLEになると思います。
私も所詮素人に毛が生えた程度なのでえらそうなことはいえませんが。
>>そんなのいくら勉強したって現場では使い物にならないし、
>>誰も見ないよ。
>わたしの会社も新しい概念やシステムが導入されそうになるたびに
>独自技術にこだわる職人さんや年寄りが似たようなことを言っています。
前半の部分(現場に不要なデータや管理項目という意味)に対して、否定する
ような書き方をしたので>>88になりました。
そうではなく現場に必要な新しい概念やシステムに抵抗する 云々という
意味なら同意します。現場作業者の面倒臭がりや頭の切り替えの悪さに私も
半ば呆れ返ってますので。作業のマニュアル化や環境対応に抵抗しております。
これでは製造業としての義務だと思ってるISO9000や14000が取れません。
顧客からどう見られようがお構い無しです。顧客が買ってくれるから、給料が
貰えるという基本的な認識に欠けています。単なる時給労働者なんですね。
すっかり１さんと勘違いしていました。誠にすみません。
生産技術部門としての意見だったのですね。
DB化については私も素人なのですが、予算・賃率・工程・部品表・部材単価
の各テーブルから構成されるのでしょうか？ なるほどと感心させられました。
(まったく勘違いだったりして。。。)
>>95
２ちゃんでマジで謝られても・・・・ｗ
お客様と取引してるわけじゃないし素人と言われようがけなされようが別にかまいません。
ちなみに工程と部品表以外、（予算=メンテナは経理。賃率=メンテナは製造管理。
部材単価=メンテナは資材。）と考えられるので強い興味は湧きません。
-----
◆格安のソリューションを提案していただけるなら広告歓迎です。
捨てメアドを晒しておきます。無視することもありますがひと月に２度くらいはチェックします。
-----
技術部門が入力し、製造管理と製造現場の監督・作業者が再利用可能であればなおよいです。
UIが命っぽいですが「脳内仕様」にあるテーブルをデンパに書き綴ってゆくと・・・・。
・工程表 ：普通（生産管理の参考書や>>83の教科書に準じる程度の)な工程マスタ。
ただし、STが最大で6フィールド(段取り、後片付け、主作業の３つを人、機械の２つに分ける）
一工程ごとに、品質管理項目(0..n)、品質管理水準(0..n)、品質管理方法(0..n)、
およびSTの特性を決める数値（非表示）を最大10個格納。
・設計情報：STや品質のポイントとなるヒント情報。図面がすべて入るわけではない。
部品番号、特性名、値,etc...
例：('G13型トラクター','全長',2300,...),('G13型トラクター',基本ロットサイズ',8,...)
・作業マスタ：その工程の特性。たとえば「麺を切る」という工程について、
作業マスタ番号、作業マスタ版管理番号、作業名（※作業名がユニークである可能性は低い）
加工区（社内厨房１、製麺機係３ライン、裁断機係etc...）、所要人数
ST計算ロジック：UPDATE文で更新するロジックをSQL文(の一部)として格納。
T-SQLのSELECT..CASE..WHEN..THENに続く式部分のみを格納し
更新時に動的にSQLを生成するとよいか？と考えています。
標準作業：Word、Excel、マルチページTIFF画像などで書かれた作業標準書を格納。
・品質管理項目マスタ：
作業マスタ番号、管理項目、管理水準、管理方法、
※管理水準と管理方法は入力を補助するため、1～20個程度の辞書を持っていること。
例）「麺を切る」工程に割り当てられた「切断方法」という管理項目について
製麺機、包丁、裁断機etc..といった辞書を用意し用語と値を標準化する。
・・・・あまり生産管理っぽくない気がしないでもないですね。
当面、基礎部分を研究しながら懸案事項の解決方法に妄想を膨らませてみようと思います。
脳内工程設計は大いに結構だし、どんどんやるべきだけど
それって、プロジェクト・ソフトの範疇じゃないの？
クリティカルラインの発見とかさ。
はずれていたら申し訳ないんですが
97さんのところって、どれくらいの規模（人数）なんでしょうか？
１人や２人の零細企業であれば現場の担当者がそういうシステムをすべて考えるというのもアリかもしれませんが、ある程度以上の規模の企業であれば、やはりシステムは専門のソフト屋さんに任せた方が良いように思います。
SQL文がどうとかっていうのを現場の（それなりのポジションにいるように思われる）97さんが心配するようなことではないようなきがするんですが、どうでしょう？
むしろ、それよりも先にまとめておくべきこととかはないんでしょうか？
あるいは、システムを導入するにあたっての根回しとか。どんな立派なシステムを構築しても参加する人の意志がきちんとまとまっていなければ多分失敗すると思いますし、そうしないために準備をするのが97さんの考えるべきことではないかと。
なんか、偉そうなこと言ってごめんないさい。
100～のスレッドの続きを読む