専門家によるビジネスプロセス自動化プロジェクトのベストプラクティス。 パート1







Andrey Kochetkov-Consist Business Groupコンサルティングプロジェクト責任者*



技術仕様の開発、機能要件、またはビジネスプロセスの最適化に関連するコンサルティングプラクティスのプロジェクトは、面倒な作業ですが、統合プロジェクトの基盤を提供し、顧客の期待と予測結果を1つの図にまとめるために必要です。 Consist Business Groupのコンサルティングプロジェクト責任者のAndrey Kochetkovが、注意すべきこと、プロジェクトで発生する可能性のある問題、およびそれらを克服する方法について話し、大規模卸売業者であるdiHouseでプロジェクト管理の機能を共有します。



-アンドレイ、あなたのプロジェクトの経験について全体として教えてくださいあなたのプロジェクトはすべて、ビジネスプロセスを説明する段階を含んでいますか?



-私はConsist Business Groupのコンサルティング部門を代表しており、私たちが実施するほとんどすべてのプロジェクトは、ビジネスプロセスの調査、組織のビジネスアーキテクチャ、およびプロセス自動化の機能要件の特定に関連しています。 プロジェクトの具体的な結果は、プロジェクトの結果として顧客が正確に受け取るものに依存します。 原則として、お客様は、組織診断、ビジネスプロセスの最適化、自動化の概念の開発、組織の複雑な情報システムのアーキテクチャ、特定のビジネスプロセスまたは機能分野の自動化のための技術タスクなどのサービスに関心を持っています。 私たちはITビジネスコンサルタントであるため、通常は自動システムの実装に関連するプロジェクトに招待されます。 同時に、ほとんどの自動化プロジェクトは、規模や規模に関係なく、会社のビジネスプロセスの変化と密接に関連しています。 組織全体の調査、組織の活動の調査、ビジネスプロセスの識別と説明、組織のプロセスとその自動化における現在の欠点の検索から始めます。



-ほとんどのプロジェクトに存在する最も普遍的な段階のいくつかを概説しましょう。 簡単に説明してください。



-現時点では、コンサルティングプロジェクトを実施するための独自の方法論を策定および開発しています。これは、多数の大規模プロジェクトの経験を吸収し、さまざまな業界の企業や組織との連携で実証されています。 すべてのプロジェクトは、最終的に顧客が受け取るものを正確に特定するという事実から始まります。 結果が期待されるプレゼンテーションまたはフォーマット。 プロセスのプレゼンテーションスキームとプロセスの説明(テキスト形式、プロセスマップの形式)の両方に応じてオプションを提供し、後続のドキュメントのプレゼンテーションのオプション(機能要件、機能アーキテクチャ、自動化コンセプトなど)について話し合います。私たちは、達成されたすべての合意について議論し、結果に関する合意という形で記録します。 したがって、プロジェクトの初期段階では、クライアントは最終結果と共同プロジェクトチーム(プロジェクトの目標と結果の共通の理解)に自信を持ちます。



プロジェクトチームは、従業員と顧客の従業員で構成されています。 プロジェクトのチャーターが作成され、開始会議が開催され、プロジェクト管理へのアプローチが開発されています。これにより、考えられるリスクを考慮することができます。 次に、主要な従業員との会議のスケジュールであるプロジェクト計画が作成されます。 そしてその後、私たちのチームは主要な設計作業を開始する準備が整います。 設計作業を実行するプロセスでは、ドキュメントに精通し、インタビューや調査を実施し、顧客施設に移動し、客観的および主観的な情報を特定する他の方法を使用し、レポートドキュメント(プロセスの説明、プロセス図、分析レポート、その他のドキュメント)を準備します。 さらに、開発されたすべての資料および文書は、特別に開発された手順に従って顧客と合意されます。



プロジェクトが徹底的な検査を必要とする場合、主要な主要従業員だけでなく、プロセスに直接または間接的に影響を与える従業員とのインタビューも実施します。



プロセスの説明の段階の後、プロジェクトチーム(顧客の従業員を含む)は、組織のビジネスアーキテクチャを完全に理解し、組織のすべての欠点と強みを提示します。 したがって、もう1つの問題、顧客コンピテンスセンターの形成が解決されます。



プロジェクトのさらなる段階は顧客に依存します:プロセスの最適化が必要な場合、プロジェクトチームは内部セッションを実施し、経験、欠点の特定方法、最適化基準を使用して会社が改善すべきことを分析します。 これはすべて、組織の強みとビジネス上の制約を考慮して解決されています。 最適化には、たとえば、トップマネジメントの機能、組織環境の制限、技術的な制限、市場の制限などの制限要因があります。 組織の強みと最適化中の競争上の優位性は最も厳しい制限です。これは維持および開発が必要な最も価値のあるものであり、企業が目標を達成するための飛躍を支援するためです。



さらに、プロジェクトチームは、クライアント企業の主要な従業員と議論するための最適化提案、最適化されたビジネスプロセスのプロジェクトを開発します。 私たちはお客様と会い、新しいプロセス設計に協力し、それらをどのように改善できるかについて共通の意見を持っています。



-情報システムの実装時に、既存のビジネスプロセスが変更される頻度はどのくらいですか?



「彼らは常に変わります。これは避けられません。」 問題は、これらの変更の大きさです。 各組織には独自の詳細があります。 一部の組織は、競争力の向上に努めており、複雑なプロセスの大規模な変更に対応しています。 一部の企業は、個々のプロセスのコストを最適化すること、または特定のプロセスインジケーターを改善することに重点を置いています。 私たちは常に、会社や組織に最適なオプションを探している顧客と一緒にいます。それは、目標を迅速に達成するのに役立ちます。



場合によっては、最適化の結果として、プロセス全体ではなく、プロセスの特定の機能のみが変更できます。 ただし、競争力の向上を目的とする組織では、組織の責任者またはキーパーソンが当社の申し出を受け入れた場合、各プロセスを変更すると顧客のサービス品質(外部、内部)に影響することが理解されているため、企業は既存のプロセスを大幅に変更し、新しいプロセスを構築する準備ができていますそれは最終的に戦術的および戦略的な競争上の優位性に影響します。 国内コストの最適化に重点を置いている企業は、プロセスを大幅に変更する準備ができていないことがよくあります。 原則として、彼らは特定のプロセス指標を改善することに関心があります:オペレーションの速度の増加、プロセスのコストの削減など。



-ビジネスプロセスの最適化の作業で考慮すべき最も重要なことは何ですか?



-プロセスモデルが最適化された後、整合性についてモデルを分析し、最適化されていないプロセスと調整する必要があります。 新しいプロセスを備えたビジネスアーキテクチャは、明確で透過的で信頼性の高いパフォーマンスを提供する必要があります。 この段階で、関連する機能分野間のビジネスアーキテクチャのすべての不整合が特定されます。 整合性分析の後、すべての最終プロセスが顧客と合意されます。



-このモデルは自動化プロジェクトを開始するのに十分ですか?



そうでもない。 このモデルは、次の段階で開発され、後続の自動化プロジェクトの開始点として、およびITソリューションの選択のために使用される自動化の概念を開発するのに十分です。 自動化プロジェクトの時間枠と予算を理解するには、顧客にとって自動化の概念が必要です。 クライアントが期限、予算を理解するために「トップレベル」の概念を必要とする場合、前のステップで得られた十分な情報で十分です。 たとえば、自動化プロジェクトの機能範囲を理解するために、より詳細な概念が必要な場合、概念には機能要件と統合、セキュリティの要件が含まれます。 これらの要件は、最適なソフトウェアプラットフォームを選択するプロセスでも使用されます。 次のステップは、技術仕様の開発です。



技術的なタスクを開発するとき、特定の情報システムの制限に準拠するために特定された要件を分析する作業が実行されます。 すべての要件は、特定のソフトウェアプラットフォームの使用に関して分析および詳細化されています。 さらに、情報セキュリティの詳細な要件がTORに含まれており、情報システム間の統合の要件が慎重に検討され、将来の情報システムの必要な指標が指定されています。



-異なる顧客のプロジェクトを比較する場合、クライアントは国有企業か商業組織かなどによって異なりますか?



-はい、もちろん違います。 顧客が属するカテゴリに応じて、プロジェクトの特定の段階により注意を払う必要があります。 各顧客は個人ですが、政府機関と商業組織の間には一定の違いがあります。 たとえば、手順と承認条件の違い、指定された責任者の権限の範囲、意思決定の詳細。 したがって、国有企業では、ほとんどの場合、従業員のグループまたは形成された委員会によって決定が行われ、問題を調整するために、結果を提示する正式な部分に注意を払う必要があり、最終的な文書を内部ポリシー、方法、基準などに合わせます。 -結果を達成するためのプロジェクトの組織のアーキテクチャ、リスクを考慮し、高品質の結果をもたらすプロジェクト構造を構築する お客様へのLtat。



-あなたの意見では、各段階で最もよくある間違いは何ですか? そして、あなたはそれらを避けるために何を提案しますか?



-ビジネスプロセスを検討する場合、顧客との作業を正しく構築し、会議のスケジュールを正しく構築し、承認手順を正しく検討することが重要です。 大きな間違いは、顧客に馴染みのない用語の使用である可能性があるため、顧客の内部規制文書を慎重に調査し、通常の用語と形式を使用します。 場合によっては、1つのプロセスまたはプロセスのブロックのパイロット調査を実施し、共同の議論で結果を検討する価値があります。 また、ブレーンストーミングセッションを実施して、この顧客からの主要なビジネスエキスパートが関与して受け取った情報を確認し、このビジネス分野で採用されている用語に結果を一致させます。



ビジネスプロセスのスキームと説明を開発する場合、詳細への注意が低いため、または顧客からの重要な情報が不足しているために、困難が生じる可能性があります。 ここで、クライアントは自分のプロセスを非常によく知っているが、何らかの理由でニュアンスを伝えることができなかったか、プロジェクトチームがそれらを特定できなかったことを理解することが重要です。 この場合のコンサルタントの技術は、試験中にすべての「秘密」が「明白」になるということです。 受け取った情報を適切に処理し、顧客とやり取りするときなど、何かが歪められたすべての理由の分析を実行できる必要があります。



もう1つの「落とし穴」:誤って構築された場合、ビジネスプロセスと顧客を調整するプロセスは無限になります。 これを回避するには、顧客がプロセスを調整することがより便利であることを事前に理解することが重要です。 パイロットの承認を行ってアプローチを調整するか、顧客との合同会議でそれらを検討し、承認に最適なオプションを選択する必要があります。 私たちの経験では、最も迅速な合意は、共同プロセスディスカッションセッションです。



プロセスを最適化するための推奨事項の検討と開発の段階で、重要なことを見逃さないことが重要です。 この段階でエラーを排除するために、私たちは常に、顧客のビジネスの経験と専門知識を持つ専門の方法論者、研究中の組織のビジネスに精通していない新鮮な外観を持つ人々を使用しています 当社は大企業であるため、ほぼすべてのビジネス分野で主要な方法論者を引き付ける機会があります。



この段階で組織の将来のビジネス構造が設計されているため、プロセスの設計は非常に重要な段階です。 プロセスを設計するときは、顧客から隔離してプロセスを設計するべきではありません。 プロセスの設計は、クライアントとの緊密な協力の下でのみ行われます。オプションを提供し、最適なプロセスモデルを検討し、探します。



企業情報システムの近代化に関する推奨事項と組織の企業情報システム(CIS)を近代化するスケジュールを作成する場合、顧客のIT部門に特別な注意を払うことが重要です。 IT部門には技術的な制限がある場合があります(アーキテクチャ上の制限、技術的なポリシー)。 また、自動化の概念を開発する際には、IT部門の実装における蓄積された経験を考慮する必要があります。



ビジネスプロセスを自動化するための機能要件を開発する段階で、開発された機能要件が十分に高品質で詳細ではないという事実に遭遇する場合があります。 このような場合、プロジェクトチームの方向を正しい方向に調整するために、システムアナリストを関与させる必要があります。



技術仕様の開発段階での最大の間違いは、ソリューションの完全性と完全性の欠如です。 この場合、情報システムの設計者が関与する必要があります。これは、TKの構造に明らかなエラーがあることを示している可能性があります。



このトピックは、記事の第2部に続きます。 ここにあります:



-diHouseでのIP実装のケーススタディ。

-顧客と協力する:「物事を同じように見ます」。

-自動化のための技術仕様の準備に効果的なツールを使用した経験。



継続は、当社のブログのページで間もなくリリースされます。



*会社情報:



Consist Business Groupは、LANITとSystematics Groupの主要なコンサルティング資産を組み合わせています。 このビジネスグループは、LANIT Consulting、TOPS Consulting、Sciener、LC Europeに基づいて構築されており、ロシア経済の主要セクターの顧客と連携するためのITソリューションの管理コンサルティング、開発、実装、および保守のプラクティスを組み合わせて、学際的なITホールディングにしています。



All Articles