フレームワーク構想

社長より技術部室長に紹介され g-mon に流れたこの記事「「設計基準」はあっても「設計手順」がない日本のメーカ」ですが改めてレビュー文書管理(以下レビュー)の大切さを教えてくれます。

g-mon もズット会社の設計図を書き仕様打合せしシステムを組んで来ましたが時に忙しく(面倒で)レビューを残さないで来ました。が、それがどんなに間違いであったかと気づかされました。そして今一度、ではどのような考え方でレビューを残すべきなのかその体系を整理してみよう、それが完成したらフレームワーク図となずけてみようと考えました。

フレームワーク体系

g-mon の会社の場合最上級の文書は品質マニュアルになり全体をモーラしています。ただ実際のレビューは、上記図の製造や営業などの品質文書が点在しているに止まりそれらの関連性を全体として捕える事が出来ません。この状況ですとクレームなどの発生に対し何かを改善したいと考えてもなかなか全体が見通せないわけです。

業務プロセス図

これを改善するために業務プロセス図、情報伝達プロセス図、処理プログラム、記録、を組織全体をモウラする形で構築作図しています。また、並行しどのようにこのプロセスを維持(基本プロセス横)し改善(基本プロセス縦)するかについても明確にするルールを設計しています。

文書体系図

これら各プロセス図の上位文書として業務プロセス図を繋いだフレームワーク図を作成しここに関連する文書を登録します。これにより全体の企業活動がどのように行われているか誰でも確認出来るようになり何か問題が出た時にどのレビューを確認すればよいか一目瞭然となります。また、落ちている文書などについても確認する事が出来るわけです。

g-mon の今期目標は、まずこのフレームワーク図の土台を構築しDomino/Notes上で全社員が確認できる環境の基礎を作る事です。一人では、とても無理、でもこの会社には仲間がいます。
コメント
コメントの投稿
管理者にだけ表示を許可する