今、自社開発でもパッケージ購入でも、実際に工程進捗管理システムを利用している企業はどのくらいあるのか。実情では工程情報を紙に出力し紙ベースで管理しているところが多いのではないか。
9月にJAGATで実施したアンケートでも、工務部門の課題として「問い合わせが多い」とか、「連絡がスムーズでない」という回答が多く、改善したい機能として「進捗管理精度向上」があげられている。このように工程進捗管理は現状の業務の流れと合っていないとか利用されいないという現状が多いようだ。
印刷業務向け情報管理システムを開発すると、基本的な流れとして、受注情報を入力し作業指示を発行するところから始まる。その後、工程管理として、作業計画・日程表の作成があり進捗管理を行う。作業が終了すれば原価集計を行う流れになる。
しかも実際の運用では、日程表を紙に出力して、紙ベースで進捗を管理し日報などで作業の終了や実績を集計する流れが多く、進捗管理をシステムで行っているところは少ない。
印刷物の製作を管理するための進捗管理とは、変更や次の工程への作業指示など製作工程における無駄やミスを減らす役目をする部分であり、工務業務が行っている大変な作業の部分である。そしてこの部分がシステムを利用していないという実態になってくる。
柔軟性が乏しい工程管理システム
最近では、ほとんどの情報管理システムがリレーショナルデータベース(RDB)を利用している。このシステムの特徴は表項目をベースとしたシステムで、帳票発行や帳票管理には非常に向いている。そのため受注や販売情報の管理には対応しやすいシステムである。
工程管理の部分もこの同じ仕組みで作られている場合が多く、工程表の出力までは簡単に行える部分である。
しかし実際の製作現場は、なかなか予定通りではなく、作業順序や担当を変更するなど実務はその場その場で対応が必要となり、工程管理は非常に複雑で変更が多い部分となっている。
このためこの状況を管理する工程管理システムは、かなり柔軟なものが求められるはずである。
工程管理システムでは、いくつかの課題がある。ひとつは、受注製品の変化や増加があれば、工程項目や管理項目が変わってくる。また装置の入れ替えがあれば作業も変わるので、この変化への対応がある。もうひとつは予定に対して、実際に作業内容が変更されたり、担当者が変わることがあり、さらに間に合わせるため作業を分割したり、実際の工程の中で予定作業が変化するなどへの対応がる。実際にはこのような部分が管理できないため、大きなくくりの工程の範囲でしかシステムを利用せず、それ以外は人や紙で管理する現状がある。
受注情報と工程情報の違い
受注情報は、基本的には製品仕様で納品する製品の情報のため変更が少なく社内で標準化されるような情報である。これに対して工程情報は実際にどのような作業工程を経て製品を作るかの指示情報で、しかも実際の細かな作業では社内状況で変化してしまう。
大分類での工程では、デザイン、ページの製作、校正・チェック、版下出力、印刷、後加工というあまり変化がない範囲で、予定と実績でこのレベルの進捗は追うことはできる。
しかし実際に管理したい工程とは、もっと細かな単位で、しかも並列に作業したり部品がそろったら作業を行うなどある程度リアルタイムで精度のよい進捗管理が要求される。このため、ひとつの表で管理できる情報の構造ではなくなり、受注情報とは管理する仕組みが大きく異なってくる。これを受注情報の管理と同じようなRDBの表構造で実現できるだろうか。
このため、決まった表でものを管理するような工程管理システムでは、日程表の出力くらいまでしか利用できないシステムとなってしまっている。
作業という考え方と仕組み
一般的には工程は、ひとつの流れのまとまりとして管理したい単位である。これに対して作業は実際に人や機械が行う単位である。例えば画像入力はある意味で工程であるが、実際には、複数のスキャナや複数の人が作業をしている場合がある。このように印刷物の製作工程にはいろいろな作業が必要である。計画では、一台の印刷機で印刷する予定だったのが、実際には2台に分けて印刷する場合も出てくる。またDTP作業を一人で行う予定を現場の責任者が3人に分ける場合もある。これらは、すべて一つ一つが作業であり工程の中の細分化された作業要素である。このため作業をひとつひとつ管理することが実際の工程進捗の管理であり、作業ごとに変更や連絡・確認などきめ細かい機能が要求される。
これ以外にDTPでは、作業に必要な部品や出来上がりも一緒に管理することで、次の工程でデータのミスを無くすことができる。このため、製作物と作業を一緒に管理するような考え方が出てきて、作業内容と作業部品を一緒に管理する仕組みも出てきている。
これを実現するには、対象作業という作業単位をしかもひとつの作業がまた分割され2つに分かれ、ひとつの工程から何層にも作業が分解展開されるような管理が必要である(図１）。しかもその作業は環境や状況で変化するので柔軟な仕組みが求められる。
実際には担当者、装置、そして作業という要素が管理され、進捗や実績集計などが、この単位で行われる仕組みが必要である。例えばDTP作業が2人の作業に分割されていれば、2つの作業の合計がDTPの実績であり、2つが終わっていなければDTP作業は終了していないことを管理する。
作業単位の管理に工夫
とかくRDBを利用したシステムは、帳票イメージを前提としたシステム構造になりがちである。受注情報は受注票にある項目の表構造をもつ。工程もデザイン、DTP製作、出力、印刷、後加工といった作業指示票のようなイメージの表で項目を管理される傾向になってしまう。
実際には、固定化された表項目のイメージでシステムを組むのは工程管理には向いていない。ひとつひとつの作業単位を大きな工程のくくりから親子関係でつなぎ、受注一品の作業が工程から作業、さらに分割された作業とつながるような仕組みが求めらる。
工程から作業がツリー展開され、これらが並列に作業が進むものとひとつに集約される作業を管理できることが望まれる。これはワークフローを自由に設定し、変更、分割できるようなワークフロー管理と似ている（図２）。
しかも作業進捗を参照するには、工程から作業を掘り下げて参照できるような、いわゆるホームページのようなハイパーリンクで情報参照できる機構が必要になる。
このためには、RDBで帳票項目を管理するような仕組みではなく、部品展開を行え、部品構造を自由に設定できる仕組みが必要になる。これはある意味では、オブジェクト指向のデータ管理の仕組みが必要であり、XMLのような構造のドキュメント構造になってくるのが工程情報だと思われる。
ＭＩＳページ
経営管理情報の有効利用から管理情報システム構築のポイントあるいはEDI、CIMの動向等、幅広い情報を提供しています。
この記事にご意見のある方は、こちらのメールアドレスまで。
図１
図２
2004/11/17 00:00:00