Clever Geek Handbook

ERP：プロジェクトの開始。 クライアントからの代替ビュー

UPD：盗作で告発されたため、記事のタイトルを変更する必要があります。 記事自体に変更はありません。



免責事項：投稿は客観的なふりをしていません。 クライアント側でERPを実装した経験があまりないことに基づいた、非常に主観的な意見。 この記事では、ERPシステムの実装に関する契約を締結する前に行うことが推奨されるいくつかのアクションについて説明します。



「コンサルティング」とは何ですか？



用語の決定を開始することをお勧めします。



ERPを導入するとき、ビジネスの代表者は、「コンサルティングサービス」の概念を、実施する会社の代表者とは多少異なるように理解しているように思えます。 明確にしてみましょう。 ウィキペディアの定義：



「コンサルティング（コンサルティング）-財務、商業、法律、技術、技術、および専門家の活動の分野における幅広い問題について、マネージャーおよびマネージャーに助言する活動。 コンサルティングの目的は、管理システム（管理） が定められた目標を達成するのを支援することです。」



したがって、プロジェクトの目標はERPシステムの実装です 。 これは、請負業者との契約で規定されているものです。 実装プロジェクトの一環として、コンサルタントはビジネスプロセス自体を監査および再設計しません。



ERP実装プロジェクトの一環として、コンサルタントは既存のプロセスを分析し、ユーザーが新しいシステムに正しく反映することを望んでいます 。 システムの外部で実行が計画されている操作は、通常、注意の対象外です。



原則として、 特定のビジネス指標を達成するためのプロセスの包括的な監査（たとえば、在庫残高の削減、クライアントへの納期の短縮）は、別の契約の下で別のお金で別のプロファイルの会社に相談することによって実行されます。



実際、ERPを実装すると、ビジネスインジケーターの「最適化...、増加...、最小化...」が発生しますが、これは以下のポイントの少なくとも1つが満たされている場合にのみ発生します。





実装プロセス中に、ロジックを大幅に変更することなく、既存のシステムから新しいERPにプロセスを簡単に移行できる場合、ビジネスインジケーターの画期的な改善を待つ必要はありません。 すなわち ERPシステムを実装する際に、ビジネスプロセスコンサルティングとプロセスコンサルティングを直接混同しないように提案します。 ただし、ERPを実装する際にコンサルタントがビジネスタスク用の美しい非自明なソリューションを提供することもありますが、これは実装プロジェクトのルールよりも例外です。



コンサルティング会社と契約を締結する前に必要なこと



  1. プロジェクトの目標を策定し、プロジェクトに関与するすべてのビジネス代表者に提出します。 「ERPの実装を通じて企業の効率を改善する」などの合理化された定式化は必要ありません。 これらのエピソードの演習は実装者の慈悲に任せましょう。だから、誰もが契約のそのような言葉遣いを作る方法を知っています：すべてのERP実装プロジェクトが成功するわけではありませんが、最初から各プロジェクトの美しい目標が宣言されており、その達成は常に可能ではありませんプロジェクトの完了時に測定します。



    ERPシステムが必要な理由をビジネスと実行企業の両方に簡単に説明する必要があります。 結局のところ、何かが私たちにその実装の問題を考えるきっかけになりましたか？ いったい何？ なんで？ このアイデアを策定し、それを紙に記載する必要があります。



    企業では、新しいシステムが導入される理由、企業にどのような改善をもたらす必要があるか、変更が特定のビジネスユニットに与える影響を理解する必要があります。



    この場合、ビジネスは、コンサルタントとのコミュニケーション、理解できない用語での厚いドキュメントの調査、新しいソフトウェアを学ぶ必要性などの形で、さらに多くの負荷がかかる理由を理解します。 これは特に、急激な変化が予測されない部門の場合に当てはまり、自己記録を産業システムに変更する部門は石鹸のバーコードのように見えます。 質問とうめき声だけで、「システムを導入する理由」、「システムを実装した後に全員解雇されますか？」、「すべてがうまく機能します。何も実装する必要はありません！」などのコンサルタント。 費用のかかるコンサルティング時間を大幅に節約できます。



    最初に策定された目標は、パフォーマーにとって有用です。 これは、コンサルタントが顧客が開発したい方向のベクトルを理解し、いくつかの可能な解決策から問題に特定の解決策を選択する際に「正しい」基準を適用し、ユーザーとの生産的な連絡の確立を簡素化するのに役立ちます。



  2. 新しいシステムに必要な機能のリストを作成します 。 原則として、この作業はコンサルタントによる実施のための契約の準備中に実行されますが、私の意見では、クライアントは潜在的なパフォーマーとのコミュニケーションを開始する前に独立してこれを開始する方が良いです。 私たちの現実では、状況は異なります。プロジェクトは友好的なトップパーティーで「ここで生産を自動化する必要があります。 受けますか？」 そして、彼らは手をたたいても、インテグレーター会社のラインの従業員は、生産の自動化の下で、顧客がERPの「完全ではない」生産ではなく、以下のリストから何かを理解したことを認識します。



    • 生産設備とIPの統合。 さらに、制御システムとして、顧客は既存のレコーダーシステムを暗示します。
    • 生産のためのカスタム原価計算。
    • 既存の制限を考慮した製造指図のシーケンスの自動生成。
    • 販売計画に基づく長い期間の生産計画（新しいシステムでも自動化する必要があります。これは当然のことではありませんか？）パラメーターを変更し、最適な生産計画を選択する機能。


    すべてのITスペシャリストにとって、上記のタスクのすべてがERPシステムで解決されるわけではありませんが、消費財の生産と販売に精通しているが、ITからは程遠い生産会社のディレクターはどのようにこれを行うのかを知っていますか？ あなたの想像力が現実にそのような状況がいかに逸話的に発展するかを想像するのに十分であることを願っています：TOPが間違っていると言うことを誰も大声で言ってはいけません（問題の声明の1つ、その評価のもう1つ）。



    したがって、システム機能の要件のリストは次のとおりです。



    • 顧客と請負業者の間の相互理解を促進します。
    • 請負業者が価格とタイミングをより正確に計算できるようにします。
    • 請負業者による契約の準備時間を短縮します。これらの要件は、契約の「プロジェクトの機能範囲」セクションの基礎になります。
    • プロジェクトの責任の分担をビジネスプロセスの所有者に実現できます。 私の意見では、社内のIT専門家はこの作業に関与することができ、またそうすべきですが、契約の最初のリストの完全性、および契約の「プロジェクトの機能範囲」の完全性に対する責任は、ビジネスプロセスの所有者にあるべきです。


    また、これらの要件がシステムが行うべきことを示すことも重要ですが、システムがそれを行う方法を説明する必要はありません。 新しいシステムにプロセスがどのように実装されるかを決定し、記述することは、コンサルタントの仕事です。 そして、新しいシステムのプロセスが、ビジネスによって最初に提示されたように見えるという事実はまったくありません。



  3. 参考訪問を依頼してください 。 競合他社への参照訪問を組織することは不可能ですが、まったく異なる業界の企業への訪問は可能です。 どのプロセスが類似している可能性があるかを事前に分析し、それらに特別な注意を払って、完全に無関係な作業を切り離すことができます。 たとえば、家庭用化学品の生産がある場合、機械製造の生産への言及が少なくとも何かに役立つとは考えられませんが（HR-知る方法に関して）、しかし、食品加工会社を訪問するとき、あなたはすでに、例えば販売で有用な何かを学ぶことができます、出荷、売掛金の取り扱い。



    参照に代わるものは、既に構成されたシステムの重要なプロセスのデモンストレーションです。 インテグレーター企業は、独自のトレーニングおよび/またはテストベースを持ち、それらに基づいて一般的なプロセスを実証できます。



    プロジェクトでの使用にまったく不適切なプロセスが表示/実証されていても、実装に関してより具体的な質問があり、これらの質問に対する包括的な回答が得られる場合でも、これは時間の無駄ではありません。



  4. システムを実装するためのさまざまなオプションを評価します -段階的かつ「一度に」。

    比較する場合、次の点に注意する価値があります。



    • 統合の範囲と複雑さ。 段階的なバージョンでは、一時的なインターフェースにより、より多くの統合が行われることは間違いありません。 そして、この基準で「ビッグバン」と「ゾウの小片」を比較することは無意味であり、結果は先験的に知られています。 段階的な実装のいくつかのオプションを比較することは理にかなっています。 おそらく、このパラメーターを使用すると、企業のプロセスを一見すると明らかなオプションよりも最適なオプションを見つけることができます。 この問題を調査するには、実装されたシステムのアーキテクチャの知識を持つ専門家と、既存のエンタープライズITシステムの専門家を巻き込むことが推奨されます。



    • 古いインフラストラクチャのアップグレード/新しいインフラストラクチャの展開の必要性。 プロジェクトのニーズを満たすインフラストラクチャを編成するには、時間とお金がかかります。 さまざまな実装オプション-さまざまな時間とお金。 インフラストラクチャは、実装プロジェクトに伴う最も明白なタスクの1つです。 しかし、彼女が適切な優先順位を与えられていない、または単に忘れられているケースの数は驚くべきものです。



    • たとえば、新しい倉庫の試運転、新しい機器の購入、新しい市場へのアクセスなど、会社の自然開発の計画。 これらの計画がシステムの実装計画とどのように重なり、これらの計画が互いにどのように影響するかを分析する必要があります。


私の記事が、他の誰かのプロジェクトに関する「そして、それは何だったでしょうか？」という質問の数を減らすことを願っています。


More articles:


All Articles