ほとんどすべての成長する企業の生活の中で、創業以来それを提供していたシステムとプロセスが不十分になる時点があります。初期段階のビジネスは、基本的で低コストのソフトウェアシステムと、少数の主要な管理者の努力と能力に大きく依存することで成長する傾向があります。ただし、ある時点で、ソフトウェアがビジネスに追いつくことができなくなり、信頼できる従業員が過大な負担になり、企業がビジネスニーズを満たすための措置を講じる必要がある場合に機能のギャップが生じます。プロセスを改善するための措置が講じられない場合、この能力のギャップは拡大し、ビジネスの成長と競争の能力を妨げます。
この重要な転換点にあるほとんどの企業では、ビジネスのすべての領域を統合し、前述の機能のギャップを克服するのに役立つ堅牢なエンタープライズリソースプランニング（ERP）ソフトウェアを実装することを選択します。これは、ビジネスの人生において非常に重要な決定であり、リスク管理に途切れることなく焦点を当てて取り組む必要があります。 ERPは魅力的ではないかもしれませんが、成長するビジネスにとって最も重要であり、無視すべきではありません。
長年の財務管理者として、そして最近ではビジネスの総支配人として、システム全体とモジュールレベルの両方で3つの異なるソフトウェアパッケージを使用して、いくつかの実装に取り組んできました。現代の企業がERPを必要としていることは明らかであり、私は間違いなくそれを活用することに賛成です。ただし、リーダーがプロセス全体の正確な実行に集中することが最も重要です。ソフトウェア実装プロジェクトのすべての結果は今後のビジネスに影響を与えるため、この記事では、エンタープライズリーダーに、ERPの利点とリスク、および詳細なステップバイステップの実装ガイドを提供します。
ERPとは、企業のすべてのビジネスプロセスを結び付け、プロセスと機能の間のデータフローを可能にする一連のシステムを指します。これは、HR、財務、流通、サプライチェーン全体のプロセスを標準化、合理化、統合するのに役立ち、企業のさまざまな側面を1つの包括的なシステムに統合します。基盤となるソフトウェアは、統合されたプラットフォームと共通のデータ定義を使用します。今日、ERPシステムは、ビジネスインテリジェンス、営業支援システム、およびマーケティングの自動化さえも提供します。実際、ほとんどのeコマースWebサイトは、現在、何らかの形式のERPバックエンドに緊密にリンクされています。効果的なERPの実装には、適切なソフトウェアだけでなく、完全なドキュメント、主要な利害関係者からの賛同、ベンダーとのコミュニケーション、および従業員のトレーニングも必要です。
ERPの実装には標準的な時間枠はありませんが、6か月から2年かかる場合があります。タイムラインへの影響は会社によって異なりますが、会社の規模、レガシーシステムからのデータの転送、インストールされているシステムの複雑さなどがあります。後でピボットすることができる多くの戦略的決定とは異なり、企業が複数のERP実装を実行することは珍しいことです。
ERPは、生産性とデータセキュリティの向上から、スケーラビリティとコスト削減まで、すべてを提供できます。主な理由は次のとおりです。ビジネスプロセスとデータが自動化されて一元化されると、従業員は手作業が減り、レポート機能が簡単になり、業務全体をはるかに少ない中断でプロアクティブに管理できるようになります。
私が主導した注目すべきソフトウェア実装は、Oracle環境でのボルトオン買掛金（AP）自動化モジュールの追加でした。モジュールはERPシステムとは別のものでしたが、同じデータベースを使用し、完全に統合されていました。私は5億ドルの企業グループの新しい管理者であり、既存のシステムは古風なものでした。買掛金チームが20の異なるオフィスで文字通りの紙をシャッフルし、紙の承認イニシャルをチェックし、物理的な小切手で100％の支払いを行い、すべての小切手に手で署名してもらうことにショックを受けました。紙の請求書もファイルボックスに7年以上保管されていました。
全体として、これはクリーンな実装でした。改善の明確な機会を特定し、利用可能な最善のソフトウェアソリューションで積極的に追求することを決定し、プロセスを徹底的に文書化し、マネジメントバイインを求めることでリスクを管理するための初期の基礎を築きました。その結果、取引コストが大幅に削減され、経費の性質を調査する能力が向上しました。バイインが重要だったことを強調したいと思います。私は組織に不慣れで、経理チームが独自のポリシーを決定する必要があると感じましたが、CFOは当然のことながら、実装時に各構成事業の総支配人を売却させました。私たちは、ほとんどの主要なビジネスリーダー、特に経理チームと同じ場所に配置されていないリーダーのサポートを受けて実行しました。最終的に、そのAPソフトウェアは、2014年には米国とカナダ（ビジネス全体の65％）のみを対象としていましたが、その後、会社全体にグローバルに拡大されました。
それでは、ERP実装の手順を詳しく見ていきましょう。
前述のように、企業は、ERPが必要であることが明らかな明確な転換点にある場合があります。
ただし、ERPの実装は基本的にリスクの高い取り組みです。完全な障害は長期間にわたってビジネスを不自由にする可能性がありますが、部分的な障害は修復が困難な非効率性を生み出す可能性があります。私がERPの決定の巨大さを説明できる最善の方法は、それがほぼ確実に会社の恒久的な備品になるということです。金銭的投資は通常非常に高いですが、それは一般的に企業がこれまでに行った最大の資本的支出と一致する範囲である可能性があります。 Excelスプレッドシートから移行し、Microsoft Dynamics GPを実装している小さな会社の場合、おそらく$100,000です。大企業の場合、数百万ドルかかる可能性があります。さらに、それは感情的な犠牲と余分な努力の支出という点で、従業員からの大きな投資です。
リスク管理の観点から考え、ERPの実装から何を得たいかを冷静に特定します。失敗した実装のコストに対してそれを測定します。正しい答えは、現在のプロセスに固執し、ERPの実装を延期することである可能性があります。ローテクが理にかなっている場合があり、新しいソフトウェアに関連する利益がコストを正当化しない場合があります。たとえば、私はかつて、既存の面倒な経費処理方法を自動化するために、国際的に拠点を置くフリーランスのプログラマーを利用することを選択しました。幸いなことに、この取り組みでは、時間と費用のかかるシステムアップグレードではなく、20ドルのチップを含む50ドルの1回限りの料金しか発生しませんでした。
ERPの実装を決定する場合は、次の質問に書面で回答することをお勧めします。
それらの答えを取り、それらを使用して、実装プロジェクトの目標を明示的に作成します。プロセス中に、仮定を変更する必要がある、または妥協する必要があると言われることがあります。プロジェクトの要件を明確に把握することで、重大な損害を引き起こす妥協をする可能性がはるかに低くなります。
ERPを実装する理由を明確に示し、それが固有のリスクに見合う価値があると判断したら、適切なERPツールを選択し、それを正常に実装することが重要です。 ERP実装の75％が目標を完全に達成できていないため、ベストプラクティスを使用して、成功の確率を高めるためにできる限りのことを行います。
ERPを追求することを決定した後、最も重要なタスクは、ビジネスプロセスが十分に文書化され、1か所にまとめられていることを確認することです。これには、調達から支払い、注文から現金化などの明らかな主要なプロセスが含まれますが、従業員のオンボーディングやタイムカードの承認など、最もきめ細かい定期的な活動もカバーする必要があります。文書化されていないすべてのプロセスが前提となり、すべての前提にはリスクが伴うため、他の手順を実行する前にこれを行う必要があります。さらに、このドキュメントは、プロジェクトの範囲、複雑さ、および最小要件の明確なビューをリーダーシップに提供します。
ドキュメントプロジェクトの重要な要素は、各ビジネスプロセスの各ステップで情報の利害関係者を明示的に特定することです。プロセスが完全に翻訳されていない場合、または経営幹部のリーダーシップチームが下流の影響を考慮していない場合、企業の最下位レベルで実装は失敗します。この種の失敗は何度も見ました。私の最近の実装では、カスタマーサービスチームは、従来の高レベルのサービスを提供するために不可欠な、レガシーシステムに重要な顧客設定フィールドがあることを強調しました。ただし、ITプロジェクトマネージャーは、フィールドが必須ではないと誤って想定し、要件を削除しました。これは、品質保証プロセスから主要な機能を削除することにより、複数の顧客サービスの問題に直接つながりました。
ほとんどの初期段階の企業には適切なドキュメントがないため、この情報をまとめるために専門の公認会計士またはコンサルタントに外部の支援を求めることをお勧めします。特に無駄のないアジャイルな民間企業は、この演習を敏捷性とは正反対のものと見なしているため、社内チームには時間と能力が不足している可能性があります。
さらに、実装の技術面を管理し、ソフトウェアのカスタマイズを支援する付加価値再販業者（VAR）にその情報を渡すため、ビジネスが行うすべてのことを明確に説明する必要があります。 VARに提供できる情報が多ければ多いほど、VARはより良い仕事をすることができます。 VARに多くの情報を提供しない場合、VARは知識のギャップを埋めるための仮定を立てます。これらの仮定は、彼ら自身の経験に基づいているか、全体像を把握していない従業員との簡単な会話に基づいている可能性があります。 VARには厳しいスケジュールがあり、リソースを仕事に出し入れすることが不可欠です。また、ほとんどの企業は通常、ERPを1回だけ実装するため、必ずしもリピートビジネスに動機付けられているとは限りません。
このようなリスクを考えてみてください。ビジネスの30％しか理解していないVARは、ニーズの30％を満たすソリューションを提供する可能性があります。 VARとの契約を締結する前に、完全で正確なドキュメントを作成することで、このリスクを最小限に抑えることができます。これはいくつかの重要な方法で発生します：
私のより不幸な経験の1つでは、ビジネスチームは、緊密にリンクされたERP/eコマースソリューションの実装要件を指定できませんでした。基本的にお客様には利用できないウェブサイトを受け取りました。 VARの想定では、ERPシステムに緊密にリンクされている限り、顧客向けサイトのルックアンドフィールは重要ではありませんでした。ビジネスレベルでは、サイトが公開される予定だった2週間後までサイトは表示されませんでした。これを修正するために、拡張作業に数か月を費やし、追加コストで数万ドルを費やしました。 VARに想定させないでください。
適切なソフトウェアパッケージを選択することは、ERPの成功に不可欠ですが、それでもプロセスの最も複雑な部分の1つです。物事を不透明に保つことがVARの最大の利益になるため、調査を行うのは簡単ではありません。したがって、堅牢なプロセスドキュメントを特定の要件の簡潔な説明に変換し、VARにプレゼンテーションでそれらの要件について具体的に話すように依頼することをお勧めします。繰り返しますが、あなたがより具体的であるほど、VARはより具体的になります。
また、VARに、販売している他の同様の会社が使用しているソフトウェアと、VARが使用しているソフトウェアを尋ねることをお勧めします。 VARがあなたのビジネスを理解し、以前に同様の要件を処理したことがあるという兆候に耳を傾ける必要があります。 VARが、異なるビジネスが類似していると言った場合は、懐疑的になります。
もう1つの重要な考慮事項は、システムのカスタマイズを必要とするビジネスモデルに関する非標準的なものがあるかどうかです。もしそうなら、その非標準機能は本当に必要ですか？多くの次善のプロセスと慣行は、中小企業の初期に定着する傾向があります。 ERPシステムのカスタマイズは、組み込みのリスクとコストと考えてください。これは、大規模なシステムをアップグレードするたびに、ソフトウェアのカスタマイズされた部分で1回限りの更新が必要になる可能性があるためです。この実装を、既存のプロセスを再考、改善、簡素化するための瞬間として使用してください。
契約をうまく交渉することで、多くの苦痛や不満を救うことができます。ドキュメントプロジェクトに投資したので、「正常な完了」がどのように見えるかを明確に表現できます。少なくとも補遺として、契約で成功がどのように見えるかを明示的に定義することを強くお勧めします。複数のフローチャートと図を含む50ページが追加される場合は、そうです。通常、VARは契約要件を可能な限り曖昧に保ち、1時間ごとに請求することを望んでいます。彼らはまた、プロセスの完了を宣言し、最初から行われるべき作業を行うために追加料金を喜んで請求する人になりたいと思っています。 VARの定型的な合意を避け、独自の助言を得るようにしてください。あなたの側からの最適な結果は、最終的なサインオフがあなたにかかっている、固定価格の契約です。ただし、VARの条件に柔軟性がない場合は、交渉に適した同じソフトウェアの別のプロバイダーを探してみてください。
この時点で、ソフトウェアの展開を支援するために主要なプロジェクトチームを編成する必要があります。チームには、エグゼクティブスポンサーと内部プロジェクトマネージャーを含める必要があります。エグゼクティブスポンサーは、非常に上級者であり、プロジェクトの目標に対する高度な監視と責任を維持し、日々のチームが実行するための全体的な戦略を明確にする必要があります。内部プロジェクトマネージャーは、実証済みのプロジェクト管理スキルを備えた人物である必要があります。チームメンバーは通常、多くの機能領域から引き出されるため、プロジェクト管理は難しい場合があります。プロジェクトマネージャーは通常、管理している人に対する従来の監督権限を欠いています。効果的なプロジェクトマネージャーは、この課題を克服し、プロジェクトの目標を達成することができます。プロジェクトマネジメント協会によってプロジェクトマネジメントプロフェッショナル（PMP）として認定されている人は、必要なスキルを持っている可能性があります。
エグゼクティブスポンサーのレベルを超えても、組織の最高ランクからの実装へのコミットメントがなければなりません。社長またはCEOがプロジェクトに無関心であるか、著しく離脱している場合でも、組織内の他の人に、抵抗が受け入れられ、リスクを生み出す可能性があることを知らせます。
たとえば、私が保持していた財務管理者の立場で、私は買掛金の自動化の実装を推進し、それに対するコンセンサスの内部承認を得ました。ソフトウェアを公開し、中間管理職に請求書の承認方法を示したところ、何人かは参加を拒否しました。 CEOは、これらの非妥協的なマネージャーに関与して指示を与えることを拒否しました。その結果、承認は非管理職の従業員に委任されました。非管理職の従業員は、支払われる費用を適切に評価するための知識や視点をほぼ確実に欠いていました。
エグゼクティブスポンサーとプロジェクトマネージャーは、管理するための明確な目標とタイムラインを持っている必要があります。季節営業で最も遅い時期を目指し、最初の稼働日をその期間の初めに設定する必要があります。プロジェクト全体は当初の予想よりも長く実行される可能性が高く、1年の悪い時期に立ち上げなければならないことに巻き込まれたくないでしょう。
リスクを最小限に抑えることができる最後の時間は、運用開始直前の期間です。この時点で、3つの重要なアクティビティ（テスト、トレーニング、およびデータバージョン）が発生します。それぞれに十分な注意が払われていることを確認してください。
モジュールとシステム間のリンクは、データが意図したとおりに作成および転送されることを確認するために、詳細にテストする必要があります。たとえば、条件に基づいて顧客に請求書が生成される場合、売掛金モジュールによって総勘定元帳モジュールに正しいエントリが作成されることを確認する必要があります。同等の機能が確実に導入されるように、レガシーシステムと新しいERPソリューションで並列トランザクションを実行することは価値があります。テストを徹底し、結果を詳細に確認します。システムのいずれかの部分が計画どおりに機能していない場合は、稼働することを確約しないでください。
失敗したERPの典型的なケースは、1996年からSAPソリューションと他の2つのボルトオンシステムで稼働するHersheyでした。VARは48か月のプロセスを推奨しましたが、Hersheyは30か月で稼働することを主張しました。 Y2Kの前に移行を完了します。 1つのERPシステムの実装は非常に複雑ですが、個別のサプライチェーンソリューションと個別の顧客関係管理（CRM）ソリューションを一度に含めることも傲慢の兆候でした。ハーシーは、不適切な期限に間に合わせるためにテスト時間を犠牲にすることを決定しました。それらの実装は惨事でした。ハーシーはピークシーズンに顧客の注文を処理できず、その結果、1999年に1億ドルの売り上げを失いました。
通常、各機能領域から1〜2人の主要なユーザーが参加するため、一部のトレーニングはテストと同時に行われます。ただし、それらのテスターがその地域の他の労働者のトレーナーであると信頼するのは間違いです。すべてのチームメンバーが学習できるように十分な時間を割り当てて、十分に計画されたトレーニングプログラムを実施する必要があります。人によって学習スタイルが異なることを理解してください。通常、人々は新しいシステムを古いプロセスに関連付けることができるときに最もよく学びます。多くの場合、アクティビティは同じもので、別の名前が付けられています。
人々が十分に訓練されているという盲目的な信仰を持ってはいけません。多くの場合、VARがビジネスを開始する準備ができていることを初めて通知するときは、そうではありません。また、より堅牢なシステムが従来のシステムよりも多くのクリックとタスクの時間を必要とする場合でも、驚かないでください。プロセスには時間がかかり、日常的に実行するためにより多くの人が必要になる場合があります。 ERPを使用して常に人件費の節約を購入していると確信できれば素晴らしいのですが、そうでない場合もあります。実際には、機能や内部統制の改善のために、いくらか高い人件費を交換しています。多くの企業にとって、それは価値のある取引ですが、これが可能性であると期待しています。
データ変換と呼ばれるすべてのERP実装の終わりに向かって発生するプロセスがありますが、これは比較的単純で良性に聞こえます。ただし、通常は予想よりもはるかに問題があり、遅延や起動後の問題の一般的な原因です。データ変換は主に手動で面倒な作業であり、通常、データの性質に最も精通している機能リソースからの作業が必要です。データが移行されると、小さなミスが大きな問題を引き起こす可能性があるため、品質保証への堅牢なアプローチを確保することが最善です。
1つの実装では、社内のITチームに依存して、レガシーシステムから詳細な在庫データを取得し、新しく実装されたERPソリューションの同等のフィールドに正しくマッピングしました。スプレッドシートでデータが操作されると、データの要素が行間でずれ、完全に誤った属性が何千もの特定の在庫アイテムに割り当てられました。これにより、在庫が注文されたときの日々のフルフィルメントの非効率性と、完了までに6か月かかった進行中の手動クリーンアッププロジェクトが発生しました。
データ変換の重要な部分は、データクレンジングです。レガシーシステムには、新しいシステム環境に持ち込む価値のない、時間の経過とともに役に立たないデータを蓄積する方法があります。この例としては、未完成の見積もりや廃止された製品に関する情報があります。
プロセスの他の重要な部分は、データの変換です。レガシーシステムには、新しいシステムの同等のフィールドにマッピングする必要のある重要な情報があります。多くの場合、2つのシステムのすぐに使用できる調整は、完全でも単純でもありません。優れたERPシステムには、必要なデータのキャプチャと移行を可能にするユーザー定義のフィールドがあります。
プロセスの上流部分は予想よりも時間がかかるため、通常、プロセス全体が遅れます。ほとんどの実装では、後の段階のアクティビティを圧縮したいという誘惑があります。通常、従業員が次のプロジェクトに進む必要があるVARは、急いでいることへのプレッシャーを加えることがよくあります。この誘惑や圧力に屈しないでください。テスト、トレーニング、データ変換の時間枠は、何らかの理由で短縮することはできず、必要に応じて長くすることができるという考え方から始める必要があります。
つまり、これは、必要に応じて、運用開始日を自由に延長できることを意味します。計画された運用開始日は、四半期末や会計年度など、他の重要な日付と関連付けてはなりません。そうすることは大きなリスクを招きます。 CFOまたは他のエグゼクティブリーダーがERP実装のリスクを最小限に抑えるためにできる最善のことは、タイムライン全体で規律を維持し、人々とソフトウェアの準備が整っていることが十分にある場合にのみ稼働を開始することです。
稼働するときは、組織全体に、全員が最大限の柔軟性と可用性を備えている必要があることを伝えるのが最善です。最初の週末を含む最初の数日間は、多くの残業をするために彼らが利用可能である必要があることを関係者全員に知らせることをお勧めします。どんなに準備が整っていても、予想外の課題がいくつかあります。
私の最近の実装（大企業内の買収したビジネスユニットの場合）では、20年前に設定されたグローバルシステム設定のため、発売の途中でアイテムの数量が小数点以下2桁にしか到達できないことを発見しました。これにより、1オンス（0.0625ポンド）のバルク製品を正確に販売または追跡できないことに気付いたため、価格設定と測定単位の構造をその場で変更する必要がありました。これは私たちを数日後退させた小さな詳細でした。
カットオーバー日に開始貸借対照表を正確かつ即時にロードすることを優先する必要があります。 There are many ways this can be challenging, because of the detail required to accurately and completely track the assets and liabilities in subsidiary ledgers. Inventory and accounts receivable tend to be the riskiest accounts.
Data uploads should be reviewed in granular detail because errors at this stage can be very difficult and time-consuming to correct.
Once you’re operating in the new ERP system, an enhanced ongoing support capability needs to be maintained at least for the first couple of months. It is appropriate to hold regular calls, where outstanding issues are discussed and updated.
While there are many benefits to be gained from using an ERP system, its implementation is admittedly risky. However, by employing best practices and by managing the process well, the risks can be minimized. The takeaway from this post should not be a collection of reasons not to implement ERP, but rather, some ideas for improving the chances of success.
According to authors Howard Smith and Peter Fingar, “Not all process-integration problems are technical and not all about IT. Integrating computer systems is not the same as integrating the business.”