昨今、製品のコモディティ化・多様化、IOT・ビッグデータ活用による経営戦略見直しなどにより、 中小の製造業においても既存のレガシーシステムからERP・生産管理システムへの切替・導入が進められています。
一方で、「コスト削減をしたい」、「景気変動への迅速な対応をしたい」、「データを一元化し意思決定を早期化したい」など 様々な目的を掲げてスタートしたにも関わらず、導入を進めていくにつれて、「これでは現場の業務がまわらない」という現実に直面し、 いつの間にか現行のビジネスプロセスを維持・継続するだけの仕組みになってしまうどころか、導入期間・費用も当初予算を大幅に上回ってしまったということも聞こえてきます。
なぜこのような結果になってしまうのでしょうか？
原因を一言で表現するならば、導入プロジェクトにおいて、目的（理想）と現状の間をつなぐためのプロセスの希薄さではないかと思います。
変革を実現するためには、現状から少なからず変化しなければならないのですが、その変化を実際の作業に結び付けて設計・検証・教育する活動、 および、その活動管理が十分に行われていないのではないでしょうか？
一般的なプロジェクトはフェーズを区切って進められていますが、それぞれのフェーズの完了条件を満たした上で次フェーズに進んでいるでしょうか。 決めるべきことが決まっていないのに次のフェーズに進んでいるとしたら、予定通りに次フェーズを進められなくなってしまうのは、容易に想像できることと思います。
前フェーズは終わっていたはずなのに、次のフェーズになって「〇〇の要件が決まってなかった」事実が突如判明してしまうということは、システム導入以外でもよくあるのではないでしょうか。
プロジェクトを進める前に、各フェーズで実施するタスクを過不足なく設定し、定量的な完了条件を定義しておくことが、円滑なプロジェクトの推進に繋がります。
詳しい解説はこちら
フェーズドアプローチ（作成中）「〇〇の仕様が決まっておらず、このままでは開発物が納期に間に合いません。」
このような台詞をよく聞きます。なぜ仕様が決められないのでしょうか？
仕様は要件が決まっていないと決められません。現場から挙げられた様々な要望に対して要否の判断が出来ない、或いは、現場ユーザとの折り合いがつかないまま 仕様検討に入ってしまうことにより、仕様検討が長期化してしまっているのではないでしょうか。
この原因は、システム化の対象を判断する基準が不明瞭であることが一因としてあげられます。そもそも、今回のシステムで何を実現するのか、 どのように活用するのかといった将来像が明確になっていれば、そのシステム機能が必要なのか否か、判断することができるはずです。
もし、システム活用のイメージが明確になっていないままプロジェクトが進んでいとしたら、合理的な判断はできないのではないでしょうか。
詳しい解説はこちら
システム/データ活用ポリシーの明確化（作成中）「システム機能の要望を出しても、意図した仕様になっていない」「システムのプロなのだから、こちらの業務に最適なシステム機能を実現するのが当たり前ではないか」 「ベンダー側から色々な依頼をされるがいったい何をやれば良いのか分からない。」
外部ベンダーはシステム機能やソリューションについて真摯に説明をしてくれますが、聞き手側の自社メンバーにとっては、馴染みのないシステムの専門用語も多く、 何となく理解できたつもり、何となく伝わったつもりで先に進んでいないでしょうか？
外部ベンダーの視点に立ってみると、同じ単語なのに企業によって意味する内容が異なっており、クライアントの要求を理解していたつもりが、 要求とは異なる仕様になってしまっていたという経験を持つ担当も少なくはありません。
つまり、ベンダー・SIerはシステムの機能や使い方を知っていますが、顧客側の業務の詳細まで熟知している訳ではありません。 一方で、自社メンバーは自社の現行業務や特徴を熟知していますが、新システムの機能や導入方法をよく知っている訳ではありません。
このギャップを埋めるには、システム／業務の両側面にある程度精通した”通訳”が必要です。通訳がベンダー・SIer側、自社側のどちらかに配置できれば問題ありませんが、 どちらにも存在しない場合、第三者の外部を含めて補強することを検討しても良いのではないでしょうか。
詳しい解説はこちら
社内と社外ベンダー間のコミュニケーション（作成中）今のERP・生産管理システムは、一般的な製造業のビジネスプロセスをほぼカバーできる程度の機能を有していると思います。また実際の導入プロジェクトにおいても、 標準導入を掲げてスタートしているプロジェクトが殆どだと思います。
しかしながら、いざ業務設計が始まると「うちのやり方・強みになる業務だから機能開発してでも実現したい」というような要件が挙がってきて、 追加開発することになってしまうようなケースが聞こえてきます。
その原因は、「何を管理する」という視点ではなく、現行の「オペレーション（処理方法）」に注視して業務設計やシステム設計を行ってしまっていることが一因と考えられます。
様々な現場で、現在のしくみを構築した方の世代交代が進んでおり、しくみの意図を理解している人がいなくなってしまっていたり、業務の引継ぎはオペレーション方法のみが伝えられ、 その業務の意図（管理すべきポイント）を知らないまま業務を行っているような状況が散見されます。
一般的な生産管理の「何を管理するのか」といった視点でパッケージ機能を見る限り、大多数の管理ポイントは標準機能で実現できるほど、パッケージの機能は充実してきています。 だからこそ、「何を管理するのか」といった視点で業務設計を行えるような知識が求められると考えます。
詳しい解説はこちら
標準導入を遂行できるバックグラウンド造り（作成中）[Problem Case 4]において標準導入推進の話を記載しましたが、標準導入を推進する場合は、システム開発は行わないのでしょうか？
答えはNoです。
完全にパッケージ標準機能のみで業務を実現する場合、生産実績の入力等も各現場に端末を設置して、標準画面を使って行うことになります。 果たして効率的な業務といえるのでしょうか。また、生産実績データも、生産品目や数量という基本データの他にも品質情報など会社独自の管理項目もあるはずです。 このようなデータを何処で管理すれば、効果的、かつ、効率的な分析ができるのでしょうか。
今のパッケージには外部システムとのI/Fによるステータス更新処理などのAPIが予め用意されているものも多々あるので、パッケージ自体は標準機能で実現し、 必要な機能は別途開発するというようなことができるのではないでしょうか。
システム全体像を考えて、どのサービスをどのシステムで実現するのか方針（ポリシー）を決め、方針に従ってデザインすることで、効果のある有意義な開発に繋がります。
詳しい解説はこちら
アドオン／カスタマイズポリシー（作成中）エイムネクストでは、上記の様々な問題にお応えできる人材や各種サービスを用意しております。
具体的な実施内容はプロジェクトの状況に応じてカスタマイズしてご提供させていただいておりますので、まずは弊社担当までお問合せください。