助けて ERPシステム（Eng。Enterprise Resource Planning System）は、企業の内部および外部リソース（重要な物理的資産、財務、資材、技術、および人的リソース）を管理するための統合されたITベースのシステムです。 このシステムの目的は、企業内のすべてのビジネスユニット（ビジネス機能）間の情報の流れを促進し、他の企業との関係に関する情報をサポートすることです。 ウィキペディア
私は商業運転でのプロジェクトの実際の立ち上げ時に就任することになっていた。 これは、プロジェクトの中で最も困難で重要な段階の1つです。 このプロジェクトの特異性は、打ち上げ期限が動かないことでした。つまり、プロジェクトは、譲渡の可能性なしに特定の日に打ち上げられなければなりませんでした。
プロジェクトの簡単な説明
システム：Oracle eBusiness Suit、Oracle Hyperion
プロジェクト期間：1年、3段階
予算：80万ドル-10万ドル
顧客：Air Astana
開発者：BAS（25人）
プロジェクトチーム：20〜30人、ITチーム6人
ビジネス機能：財務、購買、倉庫、予算編成、人事
このプロジェクトは、私にとって興味深いやりがいのある経験でした。 私はこの投稿でカバーしようとするいくつかの非常に重要な教訓を学びました。 この投稿では、特定の技術的なソリューションと機能について説明する予定はありません。 私の仕事は、プレゼンテーション、パンフレット、書籍では通常説明されない実装の側面を共有することです。
嵐に備えて
プロジェクトがすでに7か月続いたときに、プロジェクトマネージャーの役職を簡単に任せることはできませんでした。 多くの重要な設計上の決定がすでになされています。 それらを変更する方法はなく、それらに挑戦したり質問したりする建設的な意味はありませんでした。 プロジェクト管理を受け入れる準備をするのに1.5か月かかりました。
プロジェクトの最初の数日から、理想的な嵐が近づいていることが明らかになりました。 既存のビジネスプロセスの変化の数と規模は、企業に深刻な危機をもたらす可能性があります。 私はシステム設計の初期段階に参加しなかったため、私がしなければならなかった唯一のことは、不可避の大変動に可能な限り最善の準備をすることでした。 私にとって、初めてプロジェクトに参加した新しい人にとって、最も重要なことは、困難な時期が来る前にビジネスユーザーとの良好な関係を築くことでした。 危機の間、確立されたコミュニケーションが重要な役割を果たすことを提案しました。 最初の数か月間、エンドユーザーと密接に連携し、システムの習得を支援し、トレーニングを実施し、プロジェクトチームに技術実装に関する作業を提供しました。
この戦術は非常にうまくいったと思います。 その結果、ローンチの間に、ユーザーのビジネスに、やりたいことややりたいこと以上のことを繰り返し要求する必要がありました。 その後、強力な関係とコミュニケーションが何度も助けになりました。 対立する状況では、解決策を見つけ、妥協に同意することができました。
人々は単なるシステムの要素ではありません
このプロジェクトから学んだもう1つの教訓は、ヒューマンファクターの重要性です。 さまざまなビジネスプロセス、複雑なスキーム、階層、構造を計画しました。 実践は、人々はシステムの単なる要素ではないことを示しています。 文字通り、それぞれの場合、人的要因を考慮する必要がありました。 この段階では、人々ともっと協力し、交渉し、同軸化し、和解し、仲裁し、時には脅迫することさえ必要でした。 さらに、人々は病気になったり、休暇を過ごしたり、辞めたり、誓いを立てたり、関係を台無しにしたり、理解できなかったり、学習を拒否したりする可能性があります。 このような複雑なプロジェクトでは、設計の初期段階で人的要因を考慮する必要があります。 残念ながら、多くの設計手法ではこの点について何も言われていません。
人は大きな財産です。
主要な従業員が退職すると、企業は大きな損失と損失を被ります。 人々が複雑で時間制限のあるプロジェクトを離れるとき、これは時々実装を複雑にします。 プロジェクトの実装中に、システムのモジュール全体を設計した主要な従業員が退職しました。 そのような従業員の損失は、数ヶ月間閉じることができなかった巨大なブラックホールを作成し、彼らの離職の負の影響はまだ感じられます。 主要な従業員をどのように評価して保持するかという問題は、個別の議論に値するまったく別の問題です。
紛争管理
最初に、このプロジェクトでのプロジェクトマネージャーとしての役割を明確に定義しました。これは、プロジェクトチームが完全に機能できるようにすべての条件を作成することです。 当時は、システムの技術的な実装ではなく、紛争管理と危機管理に関する作業でした。 非常に頻繁に、私は異なるビジネスユニット間の交渉者または仲裁人として行動しなければなりませんでした。 直接的な権力と圧力の正式な手段がない場合、正式ではない紛争状況を交渉して解決する必要がありました。 利害関係者が中立的な仲介者を介してのみ通信できる状況がありました。 多くの場合、ピースメーカーの役割を果たさなければなりませんでした。
社会技術システムの故障。 真実の瞬間
仕事中に出会った最大の問題は、社会技術システムの失敗でした。
助けて 社会技術システム-...人間の相互作用と労働の技術的および技術的要因の側面における労働プロセスの設計へのアプローチ。 ...この用語は、社会のインフラストラクチャ要素の相互作用、一方では社会の主体的実現、他方では人間の行動の研究を指します。 ウィキペディア
技術的な問題が発生し、社会システムが失敗したときよりも簡単に解決されます。 疲労、誤解、コミュニケーション不足には、技術的な問題、システムの複雑さ、不確実性が伴います。 これはすべて、社会技術システムの麻痺を引き起こす可能性があります。 私たちのプロジェクトには、感情、感情、忍耐が限界に達し、圧力がスケールから外れ、関係者が行き詰まりに陥った瞬間がありました。 このような状況では、誰かが落ち着きを保ち、共通点を見つけ、プロジェクトの主な使命と重要性を思い出すことが重要です。 幸いなことに、私たちは長い交渉と相互譲歩によってこの問題を克服することができました。
プロジェクトチーム
このような複雑なプロジェクトでは、有能で意欲的なチームを持つことが重要です。 幸運なことに、偶然に仕事をしたチームは本物の専門家で構成されていました。 チームは何とか信頼とサポートの雰囲気を作り出し、ストレスの多い状況や負荷に対処するのに役立ちました。 さらに、プロジェクトの作業では、限られたリソースで短期間で結果を出す必要があるため、従業員のモチベーションが非常に重要です。 幸いなことに、プロジェクトチームの各メンバーは、プロジェクトの重要性とその重要な役割を理解していました。
一般に、このプロジェクトは非常に成功しました。 そのようなプロジェクトの導入の負の例は知られており、そのいくつかは大きな失敗に終わった。 もちろん、まだ対処が必要な困難や問題があります。 しかし今、嵐は過ぎ去り、危機は過ぎ去りました。