変更管理

しばらくの間、同僚と私は変更管理プロセスの最適化に苦労してきました。 すでにいくつかの成功を収めていますが、（まずプロジェクトマネージャー）これだけでは十分ではないという非常に強い気持ちがあります。



プロジェクト：顧客の要件を満たすために、エンジニアがプラットフォーム製品を完成させています。 鉄片があるため、サードパーティのサプライヤに注文する多数のコンポーネントの生産（アセンブリ）もあります。



変更とは何ですか？ 当社の製品にはプラットフォームがあります。つまり、購入者とそのインフラストラクチャのすべての要件が上から「ハング」する基本的なデバイスです。 価格で買い手に来るとき-それは製品のためです。 製品=プラットフォーム+特異性。 製品とは、仕様とTKで説明されるものです。 しかし、その後、詳細な設計と生産の準備に取り組みます。 そして、ここから変更が始まります。 変更は、製品に対するデルタです。 つまり、Sold_Product + Delta = Produced_Productです。



変更の原因はさまざまです。



顧客の要求

お客様は既存のインフラストラクチャで当社のデバイスを使用しており、プロジェクトの開始前にデバイスが動作しなければならないすべての詳細を見つけることができない場合があります。 また、ToRの段階ですべてを予測しようとしているわけではないので、同じように、「不明な要因」が常に出てきます。 バイヤーはプロジェクトの途中で突然変更を加えることもありますが、ここでは少なくともそれを把握して請求書に追加することができますが、何も変わっていない場合でも、バイヤーのインフラストラクチャについて何かを実現しただけです-これは純粋に私たちのコストです。



コンポーネントプロバイダーの変更

デバイスには多種多様なコンポーネントが含まれているため、サプライヤーが変更された場合は、デバイスの設計を新しいサプライヤーのコンポーネントに適合させる必要があります。 時には私たち自身がサプライヤーを変えます。なぜなら他の方がより安く/速く/より良く、時には人生が私たちを作るからです。 コストを削減するために、カタログコンポーネントを使用しようとしますが、このために他のパーツを「ファイル」する必要がある場合があります



エンジニアによる最適化

一般的に、エンジニアはプロジェクトで主導的な役割を果たします。 そうでない場合、コレクターが収集するものはなく、売り手が販売するものはありません。 しかし、大きな強みには大きな責任が伴います-エンジニアがすべてを連続して実行することで、構造について考え、より安く/標準/モジュラー/信頼性/シンプル/理想にします。 そして彼らはそれをします。 したがって、このソースから最も多くの変更があります。



生産の最適化

変更の最初の波はモックアップ段階で発生します（これは、粘土や枝から製品を作成し、それを購入者に見せた後です。その後、購入者は通常恐怖を感じ、要件を明確化/削除/追加します）。 この段階で、生産部門の同僚とバイヤーは、エンジニアにすでに最初のフィードバックを提供しています。 変更の2番目の波は、プロトタイプの準備ができたときです。 プロトタイプは、最初のデバイスのアセンブリです。 すべてが初めて一緒に成長した場合、これはシリーズの最初にすぎません。 何かがうまくいかなかった場合、変更の2番目の波はここから始まります。 第三波-大量生産の完全な開始。 その後、例えば、はんだ付けよりもねじれの方が速いことが明らかになり始めます。 4番目の波は、最後のデバイスがまだ製造されておらず、最初のデバイスがすでに動作していて、それらのデバイスで保証ケースが発生し始めるときです。



他のサイドプロジェクトからの教訓

さまざまなプロジェクトですでに多くの製品がプラットフォームから成長しています。 一部のプロジェクトは同時に進行し、少し前のプロジェクトはすでにプラットフォームの同僚（ベース製品を絶えず改良している）と現在のプロジェクトの設計を完了している人々の両方にフィー​​ドバックを提供します。 これは、「サプライヤXを使用しない、品質があまり良くない」、または一部の設計変更が顧客に受け入れられなかった、何かがこの他のプロジェクトに保証の下で絶えず返されるなどの教訓かもしれません。 私たちは会社の他のプロジェクトを非常に注意深く監視し、同僚を心配し、彼らの過ちを最大限に考慮に入れるか、成功事例を採用しようとします。 そして、今始まったばかりのプロジェクトは、私たちから情報を受け取ります。



***



ご覧のとおり、製品のライフサイクルの変化と段階の非常に多くの原因により、変化は避けられないだけでなく、多数あります。 そして、それらは雪崩のようにさえなり得ます（例えば、モックアップ後）。 さらに、各変更は、チェーン、サプライヤ、および他の部門に影響を与える可能性があります。 したがって、これらの変更を管理するプロセスを実装し、プロジェクトの変更管理の責任者を任命しました。



誰かが何かを変更したい/必要があるとき、彼らは最初に変更を定式化し、変更の責任者に提示します（一般的な言い方では、彼は私たちの裏切り者ですが、誰もがこの名前を好きではありません）。 彼は変更を見てから、各部門（エンジニア、生産、購買、営業）、調整の技術的意義、およびそのコストを調整します。



変更のコストは、変更自体のコストとその結果のコストの2つの部分で構成されます。



たとえば、エンジニアによると、設計の変更には120時間かかりますが、よりシンプルなコンポーネントをサプライヤから購入することができ（Xのお金で安く）、生産中に5時間節約できます。



そして、これらの変化のコストから変化の結果を差し引いたものから、変化の経済的実現可能性が得られます。 また、その後のコスト削減について話しているのではなく、信頼性を改善することについて話しているため、変更によってコストが増加するだけのようです。 この場合、保証部門に持ち込み、保証サービスの節約を計算する必要があります。 実際には、保証部門が常に関与する必要があります。 そして時々、ネジの1つを取り外して節約できるように思われますが、1年でこの節約が飛んでいる部品に流れ込み、すべての2台目のデバイスが保証期間内に返品されます。 以下にそのような話をします。



したがって、最初に技術的な評価を行い、次に経済的な評価を行います。 今、私たちは一時的な評価が必要です：計画部門が来て言います：もちろん、あなたたちはすべてこれほど素晴らしいことを考えましたが、私たちがこれを行うと、愚かなことに計画に従って、すべてのデバイスを時間内に完了してお届けする時間がありません。 次に、売り手と買い手をつなぎます。 バイヤーはサプライヤーに行き、コンポーネントをより早く作成/配送するように依頼します（金銭のため、時には支払い期限のため、時には私たちと仕事をするのが好きではありません）。 営業担当者は購入者のところに行き、「デバイスの信頼性を0.1％高める方法を考え出しましたが、もう少し時間が必要です。 1週間後に罰金なしで配達できますか？」 しかし、デバイスが安くなると、これを購入者に説明することはすでに非常に困難です。 時々（変更による節約が直接非常に重要な場合）、買い手と分かち合うことができます。時々、故意に配送を遅らせます（この場合、遅延ペナルティが変更の結果のコストの一部になります）。



しかし、申し訳ありませんが、少し先を走りました。



ソースに関係なく、各変更はイニシエーターによってレジストリに入力されます。 追加の通知は修飾子によって受信されます。 彼はイニシエーターと変更について話し合い、部門ごとの技術的および経済的評価についてさらに推進します。 各部門から評価を受け取ると、総コストに追加されます。



実際には、私たちが持っている変更（ソフトウェア、ハードウェア、プロセス、およびサプライヤの変更を含む）は、プロジェクトごとに最大で1000に達する場合があります。 すべての変更を実行することはリソースの浪費です。 そのため、いくつかの指標に特定のしきい値を実装しました：変更のコスト、結果のコスト、時間の変更。 相対的に言えば、変更が時間の変更につながらず、組み立て中に1時間を節約し、エンジニアから2時間を必要とし、すべての部門で拒否を引き起こさない場合は、ただちに「承認済み」ステータスに移行します。



週に一度、変更のレジストリについて議論するのに1時間費やします。 これは変更委員会の会議です。 プロジェクトマネージャーと各部門の代表が出席します。



変更がしきい値を超えた場合、会議で詳細に議論し、変更は理事会によって承認されるまで承認されません。 小さな変更は、同じ会議でチェンジャーによって簡単に要約されます。 はい、最初は小さく見えたがボード上でさりげなく言及されていた変更が突然、原因不明の要因の嵐を引き起こしたのはたまたまありました。 ボードに引っかかることもあれば、発生することもあります。



ステージ：

「思いついた」-「評価した」-「話した」-承認または却下



ボードは変更を拒否する場合があります。 この場合、論理的根拠が記述され、変更は拒否されたステータスでレジストリに残ります。 すでに裏切り者とは別のエンジニア自身が集まって、拒否された変更について話し合うことがあります。 エンジニアが変更方法を見つけ出し、より適切になるように、変更がこの状態から再び「思いついた」状態に戻ることがあります。



変更が承認された場合、チェンジャーの作業はそこで終わりません。 彼はプロセスを調整して、すべての参加者が実際の骨を正確に、どのように、いつ変更するかを把握し、追跡します。 エンジニアが次のように言っているからです。50時間以内にそれを行うと、100時間を費やすのはそれほど単純でも現実的でもないことが突然わかります。 または、メーカーは、この変更によりアセンブリが20分速くなると言っていますが、実際には何も変わりません。



月に一度、理事会は、実際に行われたように、既に行われた変更を議論するために拡張会議を行います。 改善が実際には追加コストにつながることが起こります。 時にはエンジニアは、はい、ごめんなさい、間違いが出てきた、それはどういうわけか悪いですが、それは保証で良いかもしれないと言うことがあります。 これを行うには、1〜2年待つ必要があります。



歴史：かつて、1つのプロジェクトが終了してから3年後に、変化の結果が私たちを追い越しました。 深刻な変化が取締役会にもたらされました。 2つのプロジェクトの取締役会は同時に来ました。それらはほぼ同じ段階で、一般的に非常に似ていました。 変更は高価で、重大なコンポーネントでしたが、エンジニアは信頼性の向上とアセンブリの簡素化を約束しました。 プロジェクトAはためらい、承認されました。 プロジェクトBはためらい、拒否されました。 プロジェクトAは、設計を完成させるための資金を投入しました。 見積りは非常に近似していることが判明し、変更の総費用は見積りを半分に上回りました。 プロジェクトBは笑い、喜びました。 プロジェクトAで組み立てると、これは単純化ではなく、その逆であることが判明しました。 マットを使用したプロジェクトAは、変更をロールバックするかどうかを考えていて（すでに手遅れでした）、アセンブリにもっとお金を費やしました。 プロジェクトBはすでに笑っていました。 プロジェクトは降伏し、時間通りに顧客に届けられました。 初年度-フライトは正常です。 プロジェクトAは、最終的にプロジェクトの利益が予想よりも控えめであることが判明したため、学んだ授業で後悔しました。 2年目-飛行は正常です。 3年目は保証の最後の年です。 そして、ここでプロジェクトBで爆発しました。「重大なコンポーネント」は、修正なしで雨が降りました。 デバイスの3分の1は、ほぼ完全な再組み立てに戻りました。 費用はすべての利益を食べました。 Changeのおかげで、Project Aデバイスは今年も完全にリラックスして生き残りました。 「深刻なコンポーネント」の変更は、3年後に突然報われました。



変更を処理するのが最も難しいのは、承認後の調整です。 委員会は承認し、エンジニアは仕事をし、設計に変更を加え、静かに眠っています。 しかし、すべての変更が購入者に届くように、それらからコンポーネントのサプライヤー、メーカー、その他の参加者に至るまで、これがチェンジャーの仕事が最もよく現れる場所です。 特に、生産開始後に変更が発生した場合。 ここでは、生産の責任者と一緒に、どのデバイスの変更がすでに行われ、どのデバイスの変更が行われていないかを理解し、すでに組み立てられたものをどうするかを話し合う（再組み立て、別の方法で使用する、またはそのまま配送する）ことがサプライヤーに伝えるために非常に重要であるため、別のコンポーネントが必要であること、バッチ全体の注文を既に行っている場合、アセンブリの指示と図面を書き直します。 詐欺師はこのすべてを行う人ではありませんが、すべての人の間を走り回り、すべてが起こり、誰もが何も忘れないように蹴るのは彼です。 私たちの記憶では、人々が並んで座って鉛筆でテーブルに沿って歩き、何が行われ、何が行われなかったかを確認してから、このテーブルに署名した会議がありました。 ハイテク機器の製造におけるハイテクの時代において、私たちはまだプレートのチェックマークに頼るのは恐ろしいですが、時にはこれが唯一の方法です。 変更の存続期間を追跡するために、変更の一連の異なるステータスを実装しました。これにより、たとえば、購入で既に議論したものと、まだ議論していないものが明確になります。 「承認済み」のステータスと「完全に実装済み」のステータスの間には、さらに20個のステータスがあり、その間に変更がジャンプします。



「完全に実装」も、変更に伴う変更の終わりではありません。 変更はまだレジストリに存在するだけではありませんが、部門は実際のコストに関する情報も作成し、変更は一般的なレジストリの取締役会で確認されます。 プロジェクトの終了後（すべてのデバイスのリリースと購入者への転送）、変更のレジストリは、プロジェクトの他のすべての商品と一緒に保証部門に転送されます。 彼らは、追加の節約またはコストにつながったかどうかにかかわらず、保証フェーズの変更がどのように行われたかについての情報を入力します。



実際のコストを追跡する方法：各変更には識別子が割り当てられます。 たとえば、エンジニアの数時間を配布するときは、プロジェクト間、プロジェクト内、トピック間、トピック内でそれらを配布します。識別子のみを使用して、異なる変更間で「変更」を行います。 コンポーネントの価格はより複雑です-実際には、1つ1つ付属しています。 通常、変更を理解するために、サプライヤに2つの提案を依頼します。1つは変更のある部分、もう1つは変更のない部分です。 これら2つの文の違いは、変化の本質的な骨です。 メーカーも同じことをします。



変化のライフサイクルの別の段階に注目する価値があります。 それは、それが起こったプロジェクトの外ですでに起こります。 長期的に見れば、実際の節約に値し、それをもたらすことが証明されたこれらの変更は、現在のプロジェクトの変更委員会とプラットフォーム変更委員会にもたらされます。 最初に、製品は修正されたプラットフォームであると述べました。 そのため、プラットフォームも静止していません。 また、小規模なプロジェクトの変更は、多くの場合、プラットフォームの開発に影響を与えます。 プラットフォームのバリエーションがこれに食い込むこともあれば、データベースに変更を加えることもあります。



それが私たちが変化に取り組む方法についてです。 もちろん、これは変更の簡単な紹介です。 たぶん、私たちは彼のことを忘れたからではなく、彼が私たちにとって当たり前のように思われるからだ。 共有していただければ嬉しいです



PS：私たちはすでにこの記事を終え、同僚に目を向けました。 彼はため息をつき、3つまたは4つのフローチャートを追加できる言葉が多すぎると言いました。 しかし、私たちの経験では、多くの人がフローチャートを読むのが困難であり、物語は通常簡単になることが示されています。 どう？