ERPの実装を開始する方法

前の記事で、ERPシステムとは何か、この場合のソフトウェアシステムの実装が実際のメリットをもたらすケース、およびERPを選択する際の検討事項について説明しました。 そして今、私はERPシステムから実用的な利益を得る方法についてお話したいと思います。 そのためには、ソフトウェア製品を実装する必要があります。

ソフトウェア製品の導入については、一連の記事「ソフトウェア製品の実装。 ビジネスコンサルタントの仕事の特徴。」 また、ERPを実装するときに、この一連の記事からの多くの推奨事項を適用することもできます。 しかし、それにもかかわらず、このシステムは中規模および大規模企業を対象としているため、その実装には、主に中小企業を対象とした以前の記事で開示しなかった機能の中から特定の機能があります。 ERPのもう1つの重要な機能は、非常に幅広い機能を備えた多機能で複雑なシステムであり、この事実も実装時に考慮する必要があります。

ソフトウェアシステムの導入の前夜に発生する最も重要な質問は、「どこから始めるか」です。 実装を開始する方法と場所を知っており、正しく動作し始めている場合、ほとんどの場合、プロセスは不必要な困難、変更、および競合なしに進みます。 そして、結果はビジネスの期待に応えます。

また、次の記事で、ERPシステムを実装するためのプロジェクトを実施する方法について説明しようとします。 そして今、私は最も重要なこと-実装の始まりについて話したいです。

実装へのさまざまなアプローチ

ERPシステムの実装にはいくつかのアプローチがあり、他の人のパフォーマンスで見た、および/または実際に適用されました。 それぞれに長所と短所、いくつかの「落とし穴」と利点があります。

原則として、ERPを実装するためのすべてのアプローチは、1Cソフトスターター、1C ERP、SAP Bussines ONE、ODOOなどの複雑なシステムにも関連します。それらについて詳しく説明しましょう。

技術仕様の準備

ERPシステムは非常に技術的な製品です。 そのため、開発者とビジネスマンの両方が、作業を開始する前であっても、実装を最大限に計画しようとすることがよくあります。 すべてが論理的であるように思われます。 このアプローチでは、技術的ソフトウェアシステムは可能な限りアルゴリズム化される必要があると想定されています。 そして、実装プロセスは、アルゴリズムと数学モデルの観点からアプローチすることができ、またそうすべきです。

実装方法：

1. 膨大な技術タスクが作成されます。このタスクでは、最小のものも含めてすべてのプロセスが考え出され、最大限に記述されます。
2. 参照条件の下で、勤務スケジュールが作成されます。

同様の技術的なタスクを作成するのに数ヶ月かかる場合があります。 私は個人的に、スペシャリストが6か月間のERPの実装に関する参照条件をどのように作成したかを見ました。 この期間中、彼は定期的にオブジェクトにアクセスし、すべてのニュアンスを詳しく調べてドキュメントに入力しました。

このアプローチからの利点は、まず第一に開発者です：

• 文書の参照条件は高価になります。 大量の作業が行われ、かなりの時間がかかります。 また、顧客は通常、質問なしで高い照会条件に同意します。
• 開発者は、どの作業を実行できるかに基づいて詳細な指示を受け取ります。 また、署名済みToRで決定が失敗した場合、変更は個別に支払われます。

このアプローチの欠点は、そのボリュームと複雑さです。 すべてのモジュール、ドキュメント、将来の作業のすべてのニュアンスを提供する包括的な技術タスクを作成することは不可能です。 システムは多機能であり、1つのモジュールを変更すると、別のモジュールを変更する必要が生じる場合があります。

同様に、技術仕様の準備に誤りがあります。1つのモジュールでの誤った決定は、他のモジュールで多くの変更を伴う可能性があります。 たとえば、一部のビジネスプロセスは正しく理解されない場合があり、実装中にドキュメントとディレクトリの一部は必要ないが、まったく異なるものが必要であることがわかります。 情報が多すぎ、システムが複雑すぎる-結果として、最初にすべてのニュアンスを定めて、考えられるすべてのエラーを予測することは不可能であることが判明しました。

私の実務では、新しいソフトウェア製品の実装について議論するために企業に来たケースがあり（私はプロジェクトマネージャーでした）、ビジネス担当者はプレーンテキストで私に語りました。 これらのドキュメントは、必要以上に多く用意されています。」 実際、彼らはドキュメントを含む膨大なフォルダーを示しましたが、そのソリューションは実装されませんでした。

「部分的な」実装

この場合、彼らは最も重要なビジネス分野とそれらを扱うためのモジュールのリストを編集します。 それらに基づいて、彼らは特定の実装計画を作成し、それが作業開始の基礎となります。

この場合、技術的なタスクも利用できます。 バルクTKが基礎として使用される作業オプションのスケジュールと同様に。 ただし、ここでの技術的なタスクはそれほど包括的ではなく、作業のさまざまな段階で独自の技術的なタスクを作成することができます。 すなわち この場合の主要なドキュメントは、作業実施計画です。

例：

実装の最初の段階として、財務と在庫移動セクションを選択します。 この作業領域は、どの企業にとっても非常に重要です。 私たちは、組織内の金融運動の特性に対処し、商品の保管と販売を研究しています。 これに基づいて、選択したサイトのERPで自動化のためのToRを作成します。 そして、このサイトに必要な機能を紹介します。

次の段階で、別の方向、たとえば生産を選択します。 また、私たちはこの方向にも取り組みます。さらに、金融と製品に関連する既製のモジュールで行われた作業（および改善の可能性）を考慮します。

この方法の主な利点は、リアリズムです。 すべてを一度にカバーすることは非常に困難です。 段階的に実装する方がはるかに簡単で、通常はエラーが少なくなります。 また、結果は実装プロセスですでに表示されています。 私自身は、このアプローチを最も頻繁に選択します。

短所-時間の増加。顧客はこれを遅延と見なすことができます。 部分的な実装では、客観的な理由と、資金調達、人的要因などに関連するさまざまな理由の両方で、作業のタイミングを遅らせることができます。 さらに、ビジネスの責任者がすべてを一度に取得しようとすると、正確な実装データの不足（完了時、正確な金額など）にも満足できない場合があります。

この作業方法は非常に慎重であり、ほとんどの場合、他の実装オプションよりも時間がかかります。 したがって、最初のアプローチ（TORのコンパイル）で、作業開始前にすべての条件と金額が事前に計算された場合、ここですべての予備的な数値は概算です。 また、さまざまな段階の技術仕様が実装プロセス中にコンパイルされます。

また、最初の作業方法では、さまざまな部門の作業の自動化を並行して実行できます。 クライアントには、会計、販売、倉庫、生産の自動化が表示されます。 ここでは、作業は段階ごとに実行されます。 また、ユニットはERPにも順番に接続されます。

アジャイルアプローチ

この場合、実装作業は準備段階なしですぐに開始されます。 受け入れられないように思われますが、ERPシステムは複雑すぎて、最初にビジネスの機能を調査してドキュメントをコンパイルしなければ実装できません。 しかし、実際には同じような仕事を見てきました。

一部の開発者は、ERPシステムの場合でも、「開始してから、それを把握する」という原則に基づいて動作します。 このアプローチによれば、予備的な一般的な実装計画が作成され、必要に応じて小さな部分に分割されます。

ほとんどの場合、同様の作業方法が「箱入り」ソフトウェア製品の売り手によって実践されています。 理由は、どのような場合でも「箱」の販売から利益を得るためであり、それらの紹介は関連サービスのみです。

この方法の主な利点は、決定が行われた直後に実装作業が開始されることです。 長い準備なし。 これがビジネスマンを惹き付けるものです。 たとえば、営業部門を自動化するという決定が下されました-彼らはすぐに働き始めました。 私たちは決めました-残り物を転送する必要があります-それらはすぐに転送されます。

原則として、この原則をうまく実装することも可能です。 しかし、それは非常に困難であり、成功するためには、リーダーの非常に高いレベルのプロ意識と、そのようなプロジェクトの実施におけるかなりの経験が必要になります。 この場合でも、専門家は他の方法を選択することが多くなります。 エラーやオーバーレイの数、人的要因の影響を減らすことができるからです。 その結果、TKで作業したり、部品で実装したりするオプションを使用すると、オーバーレイや変更を少なくして目的の結果を得ることができます。

短所-統合実装の計画の欠如。 ここで、包括的なToRの準備とほぼ同じ理由で問題が発生します。ERPは複雑な統合ソフトウェア製品であり、1つのモジュールの実装のエラーが別のモジュールの動作に影響を与える可能性があります。 しかし、もし最初のケースでそのような問題が予見しようとするために起こりすぎるなら、それではここに-計画の欠如のために。 すなわち 実装するとき、専門家は次の段階で別のユニットの作業を整理するために現在のモジュールからのデータとドキュメントが必要になるとは思わずに短期タスクを解決します。

もう1つのマイナス点-このアプローチでは、実装プロセスへの従業員の関与は、上記のいずれよりもはるかに少なくなります。 これは、新しいシステムのテストと切り替えに参加する従業員の決定に悪影響を及ぼし、新しいツールの使用を妨害することにもなります。

「少しずつですが、一度にすべて」

ERPを実装する別のアプローチとして、私は個人的に「少しずつですが、すべてを同時に」と呼びます。 このオプションは、成功する便利なソリューションでもあります。 私は個人的にそれを複数回使用しました。 そして、部分的な実装中に1つまたは2つのモジュールが動作するようになり、それらが完全に構成された場合にのみ、他のモジュールで作業を開始します。この場合、作業も徐々に実行されます。そのような明確な制限はありません。

このアプローチでは、最初のステップはプロジェクト計画を作成することでもあります。 この点で、メインステージはモジュール（1つ、次に別など）ではなく、すべてのモジュールに同時に、または選択的にいくつかのモジュールに影響を及ぼす可能性のあるいくつかのタイプの作業です。 同時に、各段階で、おおよその条件とコストが示されます。

最も一般的な場合、同様の計画は次のとおりです。

1. 技術仕様の開発。
2. 参照条件に応じた作業の実行...この項目を詳細に説明すると、作業の実行はいくつかの段階に分割されます。
3. システムテスト。
4. 試運転。
5. スタッフのトレーニング。
6. プロジェクトの完了（配信）。

同様の計画がモジュールごとに個別にコンパイルされます。これにより、作業の各段階のコストを顧客に指定し、可能な時間枠を最も正確に決定することができます。 同時に、顧客は、実装プロセス中に、必要に応じて、他の人によって計画された作業の種類を変更する可能性を必ず規定する必要があります。

プロジェクト全体の全体的な技術的要件には2〜3か月以上の作業が必要になるため、この方法は技術的なタスクを作成するよりも便利で現実的です。

ここで、顧客には各ステージの条件と金額を含む計画が表示されます。 また、作業の各段階の参照条件は個別に作成されます。それらは小さく、多大な時間コストを必要としません。 また、各ドキュメントにわかりやすい名前を付けることをお勧めします。 たとえば、「経理と財務」または「営業部」。

このアプローチの利点：

• 顧客にはすぐにプロジェクト全体が表示されます。 実装の開始前に可能な限り正確な条件とコストで。
• 請負業者は各段階の予算を明確に決定し、支払請求書を発行します。 同時に、請求書の金額には疑問が生じないため、請求書の実証や実際に費やされた時間数の計算に気を取られることなく、生産的に作業することができます。

アプローチの短所：

• お客様は、プロジェクトマネージャーが適切なレベルで各モジュールの実装機能を理解できるように、請負業者を慎重に選択する必要があります。 そうしないと、計画内の計算が十分に正確になりません。 予算が予想外に増加する可能性があり、時間枠が延長されます。 このアプローチの主な利点は失われます。
• 請負業者は、期限に間に合い、異なるモジュールに並行して従事するために、かなりの数の優秀な人材を必要とします。 すなわち 小さなチームではこのアプローチを実装できません。

計画の重要な特徴：予算を計算するとき、経験や評価の正確性に関係なく、予期しない状況に備えて追加の金額を「レイイン」する必要があります。 この量の最適なサイズは、計画された作業のコストの30％です。 これは、合意されたプロジェクトコストの計画偏差と呼ぶことができます。 これらの資金は、既存のAPIをサポートしないプログラムとのデータ交換の整理、基本ディレクトリの確定、データの転送の困難、何らかの理由で事前に予測できない作業に必要な機能の実装など、困難な場合に必要になることがあります。 .d。

これらの30％は予算で考慮されますが、必要な場合にのみ請負業者に支払われます。 プロジェクトを実装するときに「予備」なしで基本的な予算の数値を達成できた場合、素晴らしいです！ 顧客は感謝し、満足した顧客は新しい注文と最高の口コミ広告（友人や知人への推奨）になります。

それでも予備金を使用する必要がある場合は、このお金が必要な仕事の種類を正しく明確に正当化することが非常に重要です。 予算が増加したときに不快な状況が発生せず、顧客がそのような経費項目を持たないように、この金額を予算に含める必要があります。

どのモジュールから始めますか？

ERPシステムが提供できるモジュールの数は、多くの場合、「目が広まっている」と言う機会が多いため、どこから始めればよいかという疑問を提起します。 会社の作業と関連モジュールの最も重要な領域から始めることをお勧めします。

1. 金融および相互決済。 （予算編成を混同しないでください-このモジュールは後で実装できますし、実装する必要があります。現在の重要な作業ではなく、計画に関連しています）。
2. 在庫品目（在庫）の移動：保管、販売、受け取り。 在庫が正しく考慮されることが非常に重要です。在庫は通常、残高の転送前に実行され、その後、残高が転送されます。その後、作業はすでに新しいシステムでのみ実行されます。
3. 会計。 会計モジュールまたは会計システムとのデータ交換の組織の実装。 州は何も許しませんし、どんな違反に対しても、意図に関係なく、罰が課せられます。 したがって、会計および税務会計は、企業の運営にとって重要なシステムでもあります。

たとえば、高い離職率に関連して、人事が最も重要であるなど、会社が独自のニュアンスを持っている可能性があるという異議を聞くことがあります。 実際、おそらく、ERPの実装が開始された時点で、企業内でHRの何らかの自動化が行われています。 そして、このユニットのビジネスがビジネスにとってどれほど重要であっても、しばらくの間、システムで人事管理を実行できます。 プロセスで特定のエラーが検出された場合、これはマイナスになりますが、会社の存在にとって最も重要ではありません。

また、プロジェクト部門またはマーケティング部門は、しばらくの間、通常のモードで作業し、以前使用していたシステムで自律的に記録を保持することができます。

同時に、会計と税務会計に誤りがないことと同様に、コアバリュー（財務および重要）の動きに対する厳格な会計と制御は、企業が存在しない「柱」です。

ERPの実装を開始する場所、およびこのシステムを操作する方法が実践されていることに関する資料がお役に立てば幸いです。 次の出版物では、ERPの実装における私の個人的な経験について説明し、回避すべき間違いに関する情報を共有し、実装プロセス中に注意すべきこと、ERPへの移行が可能な限り効果的になるようにこの作業を構築する最善の方法について説明します。