トップページ > Q&A
「使いやすさ」「柔軟性」「スケジューリングロジック」に優れていることです。
■使いやすさ
生産スケジューラを日々業務の中で活用するためには、使いやすいことが大切です。使いにくいシステムは次第に使われなくなってしまいます。
FLEXSCHEの操作性やＧＵＩ（画面）は、ほとんどのお客様から「抜群」との評価を頂いております。
■柔軟性
製造業は実に多種多様です。たくさんの業種がありますし、さらに、同じ業種でも工場によって、あるいは工程によって、生産スケジューラへの要求は様々です。
それらの要求に応えるために、生産スケジューラには柔軟性が必要です。柔軟性がないパッケージを選んでしまったために、実稼動まであと一歩というところで導入が進まなくなり、稼動を断念してしまったというケースが、実は非常に多いのです。
FLEXSCHEは、そのような状況を改善するために開発されました。
FLEXSCHEの柔軟性の秘訣としては、
・様々な機能を組み合わせて利用できるように設計していること
・内部のデータモデルが優れていること
・簡単にカスタマイズできるような構造になっていること
などが挙げられます。これらを実現するためには、設計力、技術力、製造業の知識、等が必要ですが、それを実現できる弊社スタッフの存在が差別化ポイントにもなっているようです。
■スケジューリングロジック
FLEXSCHEのスケジューリング性能は、実際に他社製品と比較したお客様から非常に高い評価を頂いております。実際、スケジュール内容によるコンペでは、まず負けません。
これらの特長はFLEXSCHE GPのオートデモでも確認いただけますので、是非ご覧下さい。
「FLEXSCHE（フレクシェ）」は、「FLEXible（柔軟な）」と「SCHEduler（スケジューラー）」を合体させた造語です。フランス語ではありません。
生産スケジューラには柔軟性が必要、という思いを、製品名および会社名に込めています。
その名に恥じぬ製品を、今後も提供し続けてまいります。
もちろん対応しています。
それどころか、むしろ「多品種少量」「短寿命」「短納期」という厳しい環境にある場合にこそ効果的です。
もちろんあります。資源の負荷の範囲内で割付けることもできますし、無限山積みすることもできます。
もちろんできます。それらを混在させることもできます。
さらに高度な処理、例えば、一旦スケジューリングした後で、ボトルネック工程の上流をバックワードに割付け直す、といったことも可能です。
できます。スケジューリングルールで資源主導ディスパッチングメソッドを実行することで実現できます。
段取りを減らすだけでなく、さらに、納期を守りつつ段取りを減らす、といった高度なスケジューリングも可能です。
「ボトルネックの生産性が高くなるようにし、かつ、上流をそれに従わせることができるか？」という意味であれば、高いレベルで実現できます。
なお、世間一般に、「TOC」という言葉が本来の意味から離れて乱用されているようにも思います。
「TOCの５つのステップ」とは、
１．ボトルネックを特定する
２．ボトルネックを最大限に活用する
３．非ボトルネックをボトルネックに従わせる
４．ボトルネックを強化する
５．１→４を繰り返す
というものです。
１～３については、FLEXSCHEには、
・ボトルネックを可視化する仕組み （「資源負荷チャート」「資源滞留チャート」）
・ボトルネックの生産性を向上させる仕組み （「資源主導ディスパッチングメソッド」）
・非ボトルネック工程に所定の余裕を持たせて割付け直す仕組み （「作業マーキングメソッド」「作業割付け解除メソッド」「作業主導ディスパッチングメソッド」）
があります。
また、４については、どれくらい強化すればどれくらいの効果が得られるのかをシミュレートすることができます。
データの規模にもよりますが、数秒～数分といったところです。
はい、可能です。FLEXSCHE GPの標準のデータ入出力形式はCSVファイルで、仕様は完全に公開されています。
いいえ、不要です。FLEXSCHEはメモリ上に全てのデータを保持します。独自のオブジェクトデータベースを持っているとも言えます。
アプリケーション自体はPC単体で動作しますが、データをサーバーに置いて、クライアントPCでFLEXSCHEを動作させ、サーバーのデータをロードしてスケジューリングする、という運用は可能です。
１ライセンスにつき１台のPCで利用できます。
なお、大勢で使用するというケースには、細かく分けると
１．スケジュールを立案するのは１人で、その結果を閲覧するのは複数
２．スケジュールを立案する際にも複数の人が連携したい
があるようです。
１のケースのために、スケジュールを閲覧するための製品 FLEXSCHE Viewer があります。FLEXSCHE GPと同様に、様々なチャートでスケジュール内容を確認できます。ただしスケジューリングはできません。その分、低価格となっています。
２のケースのために、FLEXSCHE Communicatorというサーバー製品があります。ただし、「船頭多くして船山に登る」に陥らないようにするためには、単にデータを共有するだけではなくて、意思決定におけるルールの取り決めが必要でしょう。
通常のライセンス（シングルライセンス）では、PCにライセンスキーを接続しておくことでFLEXSCHEを実行できますが、ネットワークライセンスでは、ネットワーク上の一定数のPCまで同時にFLEXSCHEを実行できます。FLEXSCHEのインストール自体はライセンス数以上の台数にも可能で、同時起動数だけが制限されます。
ただし、通常のライセンス数に応じた費用に加え、別途ライセンス（ネットワークライセンス対応機能）が必要です。
はい。動作します。ただし、通常のライセンス数に応じた費用に加え、別途ライセンス（ターミナルサービス対応機能）が必要です。
できます。
FLEXSCHE GPのベースには、「FLEXSCHE Components」という、生産スケジューラを開発するためのソフトウェア部品（COMインターフェイス準拠）があります。さらに、FLEXSCHE Componentsには、作業を割付けるためのメソッドが用意されており、FLEXSCHE GPもそれを利用しているに過ぎません。
つまり、外部モジュールからでも、FLEXSCHE GPの保持する内部データに完全にアクセスすることができ、かつ、FLEXSCHE GPが利用しているのと同じ手段で作業を割付けることができるのです。
なお、通常の場合、FLEXSCHE GPの標準機能だけで十分です。
FLEXSCHE GPのスケジューリング機能は、標準でも非常に強力ですが、さらにそれを拡張するためのオプション製品です。
生産スケジューラの導入では、当初認識されていなかった操業上の制約やルールが、後になって重要だと判明することも多いものです。
そのような場合、「どこまでもカスタマイズできる」というFLEXSCHEの特長を活かして、独自ロジックを実装していただくのも１つの選択ではありますが、スケジューリングロジックを開発するためには高度な論理性とスキルが必要となります。
そこで「全てのお客様に必要というわけではないものの、特定のお客様では必要となることもある」という機能を、あらかじめオプションとして用意しました。
具体的には、資源占有オプション、オーダー自動引当てオプション、メンテナンス作業割付けオプション、などがあります。
FLEXSCHE GP上級オプションのライセンスは、ユニット数で管理されます。各オプションには必要なユニット数が定められており、ライセンスされた合計ユニット数以内で組合せを自由に選択し直すことができます。
ライセンス数は２８２本（2002年3月～2008年7月）です。業種は、素材、機械、自動車、電子部品、半導体、化学、飲料、医薬品、など様々です。
競合他社さんがなかなか教えてくれないのですが、独自に調査したところでは、2006年単独の国内の本数シェアではトップに並んでいるようです。
１．体験セミナー、２．メーリングリスト、３．OpenDay、４．トレーニング、５．個別導入支援（カスタマイズ開発代行、導入コンサルティング）、などがあります。
このうち、１～３は無償で、どなたでもご利用いただけます。
会員制のメールサービスです。登録済み会員だけがメールを投稿したり閲覧したりできます。
ユーザー向けメーリングリストでは、FLEXSCHEの操作方法・データ設定・ルール設定についてのご質問や、製品仕様についてのご要望などを承っています。また、スケジューリング全般についての質疑応答や議論の場としてもご活用ください。
また、開発者向けメーリングリストは、FLEXSCHE上で動作するアドインの開発方法や質疑応答や議論の場として活用いただいております。
いずれのメーリングリストも投稿内容は会員間で共有されますが、匿名投稿も可能ですので、恥ずかしがらずにどしどし投稿してください。
弊社オフィスを弊社関係各社様に開放し、皆様からの来社を歓迎するという、無料のサービスです。
FLEXSCHE製品の運用、導入、開発インテグレーション、営業活動に関すること、スケジューリングや一般的なソフトウェア技術に関する議論、四方山話など、どんなことでもお受けします。
「生産スケジューラの稼動のためには、パッケージを供給するだけでなく、その利用技術や導入ノウハウを伝授することも重要」という思いから始めました。
当初は月１回の開催でしたが、現在では、ご好評いただきまして、月２回開催しています。
日本です。
ありません。独立した企業です。
「生産スケジュール」を立案するためのソフトウェアです。
「生産スケジュール」は「日程計画」とも言います。各オーダー（注文、製番）を生産するのに必要な一連の「作業」に対して、実施する日時や使用する資源（設備・機械・工具・人）を割り当てたものです。
生産スケジュールに基いて「作業指示」が出されることになるので、生産スケジュールは、操業上の様々な制約やルールを守ったものでなければなりません。
生産スケジューラを導入することによって、
１．効率的なスケジュールを立案できるようになります。
２．計画作成の属人性を削減できます。
３．高速にスケジューリングできるので、状況の変化に素早く対応できるようになります。
４．工場全体を、将来にわたって、精度良く、見通せるようになります。
５．どこに問題があるのかが明確になり、また、各対策案によりどのような効果が得られるのかを事前に定量的に確認できるようになります。したがって、的確に判断できるようになり、また、適切な対策を早い段階で実行することができるようになります。
その結果として、
・生産性向上
・製造リードタイム短縮
・納期遵守率向上
・在庫量削減
などの効果が期待できます。
これらの効果の大きさは、工場の規模や取り組み方、景気などの外部要因によっても変わってきますが、リードタイムや在庫量に関して言えば、２０％～５０％改善されたことも珍しくありません。
ただし、注意すべきなのは、生産スケジューラを購入すればそれだけで効果が出るわけではない、ということです。たとえば、スケジューラによって「この資源がボトルネック」とわかっても、それに対して何のアクションもしなければ、それまでです。一方、そのボトルネック資源を徹底的に活用し、段取り替えを短縮し、代替資源を見つけてくるなどの努力をすれば、大きな効果が得られます。
つまり、生産スケジューラはあくまでもツールです。人間がそれを使って、判断し、行動することによって、初めて効果が得られるのです。
特に、生産スケジューラの特徴・宿命として、導入には工場全体の様々な部署の関与が必要です。また、通常の場合、導入によって業務の内容が変化します。それらの関係者（＝ステークホルダー）をどのようにして前向き・主体的に取り組ませるかで、効果は大きく異なってきます。場合によっては、各部署や社員の評価基準も変える必要があります。
したがって、ソフトウェアに詳しい若手社員に任せておけばいい、というものではありません。社長や工場長の直属部隊が、しかるべき権限と責任を持って進めるべきです。
使いやすさ、機能、価格、・・・など、様々な評価基準があるでしょうが、特に大事なのは、「工場に合うかどうか」です。工場に合わないパッケージを選んでしまうと、悲惨なことになります。
工場に合わなければ、効果が限定されます。稼動や運用に要するコストや手間に比べて効果が小さければ、誰も使いません。費やした時間やコストが無駄になるだけでなく、本来得られたはずの効果を逃したことも大きな損害です。
とは言うものの、本当に合うかどうかの判断は、正直、なかなか難しいものです。
通常、パッケージのことを完全には把握していない段階で選定しなければなりません。
また、導入を進めていくことによって、工場側の各担当者がようやくイメージをつかめるようになり、そこで初めて本当の要求が出てきて、そのときになってパッケージに合わないことが判明する、というケースも珍しくありません。
さらに、製造業は「日々新た」でなければなりません。それを支える生産システムについても、運用開始後に変更や改善が確実に必要になります。
したがって、それらの要求の変化を見越して、それに耐える「懐の広さ」を備えたパッケージを選定する必要があります。
つまり、
・工場に合うこと
・柔軟性に富むこと
が非常に重要です。
また、長く使っていくものであり、また、導入には様々なノウハウが必要になるので、
・使いやすさ
・製品および開発元の将来性
・サポート体制
なども重要な点です。
なお、工場に合うかどうかを判断するのに、同じ業種への導入実績は、参考にはなりますが、過信は禁物です。
というのは、現在本当に稼動しているかどうか不明確ですし、また、同じ業種でも工場によって様々な違いがあるからです。やはり自己責任でしっかり検討すべきです。
導入前の状況や、ゴールのレベル、進め方の巧拙、などによって非常に様々です。
あえて参考として数値をあげれば、最初の稼動までで、
期間：数カ月～１年半
システム構築コスト：数百万～数千万円
マンパワー（システム構築除く）：6～20人月
というところでしょうか。
不可能ではありません。
ただし、生産スケジューラの導入には様々な「重要ポイント」があるので、ノウハウを備えたコンサルタントやシステムインテグレーターに手伝ってもらうのが安全かつ効率的です。
実際、ユーザー企業だけで導入しようとした場合、プロジェクトが長期化する傾向が強くなっています。
早く立ち上げて早く効果が得られるメリットと、コスト等を比較して、判断してください。
ケースバイケースでなかなか難しいですが、一般論としては、「会社にとって、生産スケジューラを導入するのと、しないのとで、どちらが良いか？」で、「導入するほうが良い」と判断されればOKとなるはずです。
そのためには、判断者の思考・志向・嗜好を踏まえて、判断材料を提示しましょう。
判断材料としては、例えば、「経営環境」「現状分析」「経営課題」「経営効果」「コスト」「実行計画（実現時期、本当に実現できるのか、想定リスクとその対処）」「やる気」などがあるでしょう。
説得しているうちにいつの間にか敵対するかのような状況になりがちですが、「論破」でなく「共感」してもらうにはどうすればよいか？を考えることが大切です。
政治的には、直属の上司がダメならさらにその上から、などの手もあります。
但し、一般的には、OKが出ないのは、訴える側の視野が狭いから、であることが多いようです。
本当に必要だとの信念があるのなら、めげずに何度もトライしましょう。
例を示します。もちろん、これが絶対唯一というわけではありません。
１．会社や工場の置かれている状況、課題を整理します。
２．生産スケジューラがどのようなものなのかを調べます。
それには、
・体験セミナー・紹介セミナーへの参加
・導入事例記事を収集
・書籍やWebページから情報収集
・パッケージの評価版を試してみる
などの手段があります。
３．１、２を踏まえて、会社や工場の「あるべき姿」の案を作ります。また導入プロジェクトのメンバーを選定します。
４．導入プロジェクトを立ち上げます。
状況・課題・あるべき姿について意思統一し、プロジェクトの目的とゴール、概略の実行計画を定めます。
また、プロジェクトおよびメンバーの役割・責任・権限・各種手続きを明確化します。
５．運用方案を描きます。
どんなシステムをどんな風に使用するのか、誰が何にどのように関与するか、どんな役割を果たすか、のおおよその案を作成します。
６．要求項目を明確化します。
運用方案を実現するために必要な項目を洗い出し、要求項目として明確化します。
要求項目は、RFP（Request for Proposal）とも呼ばれます。
RFPの作成をコンサルタントに手伝ってもらうこともあります。
７．要求項目を実現する手段を決定します。
通常、システムインテグレーターに提案させ、その中から選択します。パッケージもこのときに選定することになります。
場合によっては、その妥当性を検証するために、プロトタイプを作成して評価します。そのために生産スケジューラパッケージを特定期間レンタルすることもできます。
８．システム構築を行います。
実現すべきもの・実施すべきものとしては、
・運用手順書およびマニュアル（の作成）
・既存システムとのインターフェイス（の開発）
・生産スケジューラのために必要となるデータ（の整備）
・生産スケジューラ（の購入、カスタマイズ、設置）
・スケジューリングルール（の調整）
・作業指示システム（の開発）
・実績収集システム（の開発）
・インフラ（PC、サーバ、ネットワーク、携帯端末等）の整備
・システム動作テスト
・利用者教育
などがあります。
９．実運用を行います。
・データのメンテナンス
・課題の抽出、検討
・システムのバージョンアップ
これらは永久に続きます。
運用で手を抜くと、せっかく作ったシステムがあっという間に埃をかぶってしまいます。逆に言うと、無理なく実行できるような運用方法を、あらかじめデザインしておくことが大切です。
一言で言えば、「モノと時間に関する全ての情報」が必要です。
具体的には、下の通りです。どのパッケージでも本質的には同様です。
１．工場の稼動データ
どんな機械や設備があり、いつ稼動するか
どんな人がいて、各日の勤務時間は、いつからいつまでか
２．製品の作り方
各製品を作るのに、どんな工程を通るか、どんな材料をどれだけ使うか
各工程では、どの資源を使って、どれだけ時間がかかるか
工程と工程の間にはどれだけ時間がかかるか
３．注文、オーダー
どの製品を、いくつ、いつまでに
４．現在の状況
各作業はどこまで進捗しているか
各品目の在庫はどれだけあるか
５．その他の操業制約
前後の組合せに依存する段取り替え、搬送時間、・・・
なお、FLEXSCHEの場合、データを視覚的に編集するための製品 FLEXSCHE Editor があります。入門ガイドなどに従って操作しているうちに、おおよそのところは把握できてくるのではないでしょうか。
確かにいろんなデータが必要になります。あれもこれもと考えると、あまりに膨大で気が遠くなるかもしれません。
しかし、コツがあります。
１．データの精度
全体に大きく影響するデータと、そうでないデータがあります。影響の大きいデータの整備には力を注ぎ、そうでないものについてはそれなりで十分です。
例えば、「工程毎の所要時間」の精度は、（意外かもしれませんが）まずは「それなり」で構いません。
というのは、データと実際でそれほど大きくズレません。せいぜい倍・半分程度でしょう。
また、ズレたとしても、資源毎に効率を設定してまとめて補正してしまうという方法があります。工程での滞留時間を現実に近くすることができるので、結果としてオーダー毎のリードタイムの精度もそれほど悪くはなりません。
それよりも重要なのは、「工程毎の利用可能資源」です。
よくあるのが、基幹システムには各工程の代表的な利用資源しかデータがないものの、実際には他の資源でも作業できる、というケースです。
もし他に利用できる資源が５つあったとしたら、６倍の違いとなります。
これは、たとえて言えば「高速道路の最高速度と車線数」の関係です。車の速度が違うといっても２倍まで変わりませんが、車線が１本なのか６本なのかによって通過時間は大きく変わってきます。
また、作業指示を出す際には、利用できない資源を利用するような計画は許されません。その意味でも、「工程毎の利用可能資源」は重要です。
２．まずは簡単に得られるものから
ただし、慣れないうちは何が大きく影響するかわからないでしょう。最初は、精度よりも得やすさを優先すればよいです。
既に利用できるデータがあるなら、もちろん、それを流用します。
データがない場合は、いきなり精度の高いデータを整備しようとするのではなく、まずは、簡単にやれる範囲でデータを用意します。
スケジュール結果を調べてズレの大きい部分を抽出し、その部分の精度を上げる方法を考案します。それを繰り返し、徐々に精度を上げていくことをお勧めします。
３．パッケージ非依存にする
整備するデータは、なるべく、スケジューラーに依存したデータではなく、工場に依存した、本質的なデータ形式とすることをお勧めします。
というのは、スケジューラーはあくまでも手段なので、将来変更する可能性もあります。スケジューラー自身、将来のバージョンアップで、簡単な設定で実現できるようになるかもしれません。
また、整備する前のデータは、様々なところに散在しているのが普通です。それらを集約する際には、多くの方々が関与する必要があります。それらの方々に、データを整備する時点で、パッケージのデータ形式を正確に伝授するのは困難です。
したがって、工場の情報を本質的に表せるような形式にして、パッケージに対しては、データを変換するコンバータを用意するのが良いでしょう。
ただし、規模の小さな工場の場合や、データ設計に慣れていない場合、基幹システムにデータがない場合などは、スケジューラー固有のデータモデルに合わせて、データを構築していくのも１つの策ではあります。
４．片手間ではなく正式業務とすること
データの整備・保守は、かなりの労力を必要とし、また、稼動後も永久に続きます。
したがって、担当者に片手間でやらせるなどというのは論外です。非常に重要な業務であると組織全体が認識して、妨げられることがないように配慮しなければなりません。
システムの安定性に問題がある等の致命的な不具合を除いて、通常は、「次のステップ」で実現する方が良いです（「段階的導入」といいます）。
というのは、ちょっとした機能でも、積み重ねれば工数は膨らみます。完成時期を遅らせると、段々と士気を保つのが大変になりますし、成果を得るタイミングが遅れることによる損害も忘れてはなりません。また、システムインテグレーターを困らせることはＷｉｎ＆Ｗｉｎの関係を保つためにもなるべく避ける方がよい（「情けは人のためならず」）です。
なお、システムインテグレーターに対して、当初の契約にない作業を強要するのは、違法となるおそれがあり、企業統治の上でも問題です。
ただし、どうしても必要な項目が発覚したときには、やらないわけにはいきません。その場合は、優先度を決めます。
具体的には、「実現したいこと」の１つ１つについて、本当に必要なのか、いつ必要なのか、誰にとって必要なのか、それによってどんな効果が得られるのか、それがないとどんな損害があるのか、他に手段はないのか、を確認して、それらを比較し、優先度を決めます。優先度が低くなったものは後回しにします。
プロジェクトを進める上では、様々な優先判断が必要になります。あらかじめ、そのための仕組み・手順・権限・責任を明確にしておきましょう。ことが起きる前にルールを決めておくと、後々スムーズです。
なかなか難しい問題です。
生産スケジューラの導入の特徴として、様々な部署が関与することが挙げられます。
しかも、生産スケジューラの導入前の段階では、仲がそれほど良くないことも珍しくありません。
たとえば、製造と営業とでは意見が真っ向から対立して、生産計画担当がその板挟みで苦しんでおり、その解消のためにこそスケジューラーの導入が必要、というケースも多々あります。
ここで重要になるのは、「目的は何か？」という考え方です。言い換えると、視野を広げて、大義を確認し、末節に固執するのを防ぐのです。
生産計画システムの構築は、「会社の利益のため」にやっているはずです。
各部署の利害関係が絡んでもめやすいところですが、「会社のためになるのはどちらか」を考えるようにしましょう。
議論は、「勝ち負けの争い（ディベート）」ではありません。「より良い方法を探す営み」です。
多くの場合、漠然と見れば対立しているように見えても、「その目的は？」を掘り下げて細かく分析していくと、本当に対立しているわけではないことがわかり、したがって、何らかの方法が見つかるものです。
そのためにも、導入プロジェクトの立ち上げのときに、プロジェクト自体の目的を明確にし、かつ同意しておくことが重要です。
また、案ずるより産むが易し、という面もあります。やってみてダメなら変える、ということが許される項目については、やってみるのも手です。
とはいえ、身内だけだと「小田原評定」になりがちなのも事実です。経験豊富なコンサルタントやシステムインテグレーターの助言が役立ちます。