目標の定義
ストーリー展開の最初の考えは、会社の目標を定義することです。 Eli Goldrathによると、「まさに目標」は1つだけであり、メインキャラクターはいくつかの章を費やし、痛々しいほど理解しようとしています。 「企業の成功を決定するものは何ですか？」、その疑問に悩まされ、「コストの最小化または生産能力の100％の使用が可能か？」 最初は、これらの苦痛はシミュレートされたように見えました- 利益 、それはあらゆる企業の主な目標であり、主人公がしばらくして到達するという考えです。 しかし、なぜGoldratはこれが明らかでないことを示したいと思ったのでしょうか？
最初のいくつかの章を読んでから数日後、競合会社のディレクターから、プロジェクトマネージャーやマーケティング担当者と生産効率の向上について話を聞くように誘われました。 私は常に競合他社を喜んで支援するため、招待を受け入れました。 最初の質問は、「あなたの会社が直面している主な目標は何ですか？」でした。 マネージャーは、「開発者の効果的な管理、タスクの最適な分散」と答えました。 マーケティング担当者は、「有望な顧客を検索する」と述べました。 キャッチを疑った監督たちは、目を細めて目を凝らし、答えを待っていました。 「まさに目標」について話しました。
「企業の主な目標は利益を上げることである」というフレーズは、経済学を学んだすべての人々が採用している公理であると思われます。 高品質のソフトウェア製品だけでは、顧客が自分のニーズが満たされるまで利益源にならないのと同様に、販売されなければお金になりません。 実践により、会社の従業員は職務の良好な遂行をその目標と見なしていることが示されています。 統計サンプルが少ないため、テクニカルディレクターに「私たちの会社の目的は何ですか？」と尋ねました。 「クールなソフトウェアを作り、宇宙に印をつけて」と彼は答え、「私たちのプログラムが人々を喜ばせるように」と付け加えました。 そして、世界をより良い場所にするために。」
その後、私は自分の道徳的資質を疑い始めましたが、哲学を育み始めませんでした。 したがって、意図的な決定により、会社の主な目標の利益最大化を行い、それを測定するために必要なメトリックを選択します。
*純利益
*投資収益率=（投資収益率-投資価値）/投資価値
*キャッシュフロー
正確な翻訳と常識のファンは反対するかもしれません：目標は達成できる明確に定義されたものです。 したがって、 継続的な改善のプロセスについて説明します。その結果、上記の3つのパラメーターが常に増加します。 同時改善はポジティブな効果と呼ばれることを理解することが重要です。 たとえば、投資が500万に達した場合、1か月あたり100万の利益は良好ですが、10億であれば利益はありません。 キャッシュフローも同様です。 複数のプロジェクトの資金を受け取った四半期の終わりまでに利益は大きくなる可能性がありますが、最初の2か月でプログラマに給与を支払うのに十分なキャッシュフローがない場合、会社は消滅します。
これはすべて簡単で合理的なように思えますが、疑問が生じます-継続的な改善のプロセスを開始するには何をする必要がありますか？
エリヤフゴールドラットインジケーター
代替指標を検討することが提案されています：
- 収益創出率
- 関連資本
- 営業費用率
定義：
収益生成率は、システムが販売を通じてお金を生成する速度です。
コネクテッドキャピタルは、販売可能な購入アイテムにシステムが投資したすべてのお金です
営業費用は、関連する資本を収益創出に転換するためにシステムが費やすすべてのお金です。
これらの定義は、アプリケーションの範囲をある程度残します。 それらの主なものは、それらが相互接続されており、あらゆる生産のプロセスの研究で使用できることです。 いくつかの例を見てみましょう。 オフィスの家賃、従業員の給与、物資はすべて運用コストです（マーカーや紙を転売しない場合）。 購入したハードウェアとソフトウェアは関連資本です。
スタッフの開発に費やされたお金と、さまざまな有用なライブラリとコンポーネントの開発に費やされた時間により、事態はもう少し複雑です。 IT業界の特性により、知的財産は販売可能な「もの」と見なされます。
理論の観点から見ると、主なアイデアは、関連する資本と営業費用の速度を最小限に抑えながら、収入の発生率を最大化することです。 運営費についてはすべて明らかです。オフィスに支払う金額が少ないほど、利益は大きくなります。 収入の創出もあります。今日受け取ったドルは、明日のドルよりも優れています。また、今日2ドルを受け取ったほうがよいでしょう。 それほど明らかではないのは、関連する資本が営業費用を増加させるという事実です。 例：ソフトウェアの作成に使用するコンピューターが多いほど、消費する電力も多くなります。 家具工場での半製品は、倉庫に保管し、輸送し、会計する必要があります。 教育に多くのお金が投資されたプログラマーは高い資格を持っているため、高い給料が必要です。 この観点から、より少ない資本でより高い収益率を達成することが可能であるため、自社製品の開発はカスタム開発よりも収益性が高いと合理的に思われます。
依存イベントと統計偏差
上記の理論をIT企業の実践に適用し、継続的な改善プロセスの実装に関する実践的なアドバイスを作成する前に、さらに2つの重要な概念を考えてみましょう。
- 依存イベント
- 統計偏差
最初の意味は、実稼働中の1つの操作が別の操作が完了するまで開始できないことを意味します。 たとえば、デザイナーがユーザーインターフェイスを作成するには、アナリストからこの機能の要件を取得する必要があります。 プログラマーが対応するコンポーネントを完成させるには、デザイナーのグラフィックが必要です。 テスターは、プログラマーが作業を終了してコンポーネントの安定性と要件への準拠を確認するのを待つ必要があります。 これに、サーバーチーム、顧客担当者、営業部門との可能な相互作用を追加すると、当社の手と足を結ぶかなり長いチェーンのセットが得られます。 しかし、収入を生み出すためには、最初から最後までのすべてのイベントを正常に完了することが必要であり、ほとんどの場合、順序は固定されています。
制限の理論の主な仮定は次のとおりです：チェーンは最も弱いリンクより強くありません。
つまり、収入の発生率は、チェーン内の最も弱いリンクのパフォーマンスによって決まります。 プログラマが処理できるよりも速く設計者が材料を提供する場合、設計者の速度はシステム全体の速度にプラスの影響を与えません。 同様に、プログラマーが機能をすばやく追加しても、低レベルのテスト自動化により品質管理に必要な時間が長くなる場合、テスターが作業を管理するまでこの機能は提供されません。
仮説をより明確に提示するために、ゴールドラットは学生がキャンプ旅行に行く例を示しています。 グループは、ポイントAからポイントBに完全に到達する必要があり、この問題を解決するために費やされる時間は、最も遅い参加者が費やす時間以上になります。
次に、統計的偏差について話しましょう。 設計者、プログラマー、またはテスターの速度を測定することは非常に困難です。 私たちの職業は創造的すぎます。 平均的なパフォーマンスがシステムの総帯域幅と一致するようにチームを構築したとします。 つまり、アナリストは平均して反復処理に必要な数のタスクを提供し、プログラマーは平均速度に基づいて時間通りに対応し、テスターのグループに渡します。
このような状況で最も愚かなことは、システムの速度が最終的にイベントを調整する平均速度（開発の段階）に等しくなると仮定することです。 問題は統計的偏差です。 デザイナーは頭痛の種になることもあれば、ミューズが逆に頭を悩ますこともあります。 プログラマは、予想よりも多くのコードを発行したり、突然休暇をとったりすることができます。
それでは、どうなりますか？ 4個のソーサーを取りましょう-それらは生産の段階、コインとサイコロの束になります。 コインは、受け皿1、2、3、および4を交互に訪れて、ある山から別の山に移動する必要があります。最初のステップでは、骨を投げて、山から最初の受け皿にできるだけ多くのコインを移動します。 次に、もう一度骨を投げて、最初の受け皿から、今度は落としたコインと同じ数の2番目の受け皿に移動しますが、最初の受け皿にあるものと同じです。 など、コインが「処理」されるまで。
受け皿間のコインの平均移動速度は（1 + 2 + 3 + 4 + 5 + 6）/ 6 = 3.5であるため、20回の反復で20 * 3.5-約70コインになると想定できます。
この実験では、実際の「収益生成率」が示されました。処理された59コインと接続された資本に10コインが詰まっています（ただし、開始から終了まですべての機会がありました）。 したがって、システムは予想される平均電力の84％でのみ機能しました。
したがって、結論の1つは、プロジェクトの評価において開発の速度のみに依存することではありません。 ほとんどの場合、このリンクは最も時間がかかり、したがって狭いですが、統計的な偏差の結果として、システムの速度はさらに低下する可能性があります。
さらに、統計的な逸脱から生じる関連資本がシステムの運用中に運用費用の速度を上げることを考慮していませんでした。つまり、実際の状況はさらに悪化しています。
結論
結論として、私は自分のためにしたいくつかの仮定を定式化し、議論に持ち込みたいと思います。
別のイベントの完了に依存しており、近い将来完了できない場合は、タスクを開始しないことをお勧めします。 狭いリンクを期待し、タスクの一部を事前に実行しようとして、接続された資本を作成します。 たとえば、サーバーコードの準備がまだ整っていない場合は、クライアント上のサーバーと対話するためのコードを記述できます。これにより、パラメーターがログに表示されます。 サーバーが作成されると、開発者は引き続き対話モジュールに戻り、それがどのように機能するかを再度覚えて、原因不明の違いを修正する必要があります。 未完成のタスクが多数あると、時間がかかります。私たちは常にそれらについて考え、完了する機会を求めて整理しているからです。 同僚が仕事を終えるまで、始められたことは何も終えられないとわかっているとします。 この場合、問題は将来的に機能するのではなく、プロジェクト管理レベルで解決し、ナローリンクのパフォーマンスを向上させる必要があります。
新しいプロジェクトを検索する場合、かなり多数の潜在的な顧客が処理されます。 それらの多くで、積極的な交渉の段階に入っています。 すべての生産設備がすでに読み込まれている状況が発生する場合があり、新しい顧客との交渉はまだ進行中です。 この場合、営業部に「ポットを調理しないでください」と伝える必要があります。 それ以外の場合、開始されず、おそらく開始されない可能性のあるいくつかの注文を蓄積しますが、顧客とのやり取りに時間を消費します：技術的な質問への回答、何かを調査または評価する要求など 「潜在的なプロジェクトを取り除くことを残念に思う」という議論は、合理的なものよりも大きな心理的要因を持っています。 注文の検索は、注文の開発中の生産段階の1つにすぎず、他の段階よりもスループットが高い場合は、特に収入の生成に変換されない可能性が高い場合、バインドされた資本の作成を停止する必要があります。
クライアントのプロジェクトが完了し、開発者を忙しくしておく必要がある場合にも、逆の状況がときどき発生します。 私たちは、アウトソーシングから製品開発に切り替えたい会社として、そのような場合、プログラマーの「あなたの」プロジェクトを思いつきました。 さらに、開発者はさまざまな分野で強く、オリエンテーションは正確にスキルであったため、そのようなプロジェクトの多くが開始されました。 また、10人が順番に作業を行った場合、プロジェクトの品質は最高にならないと考えられていました。 その結果、私たちは多くの「製品」を蓄積しましたが、そのうちのどれも最終消費者に届きませんでした。 収入の発生率には影響しませんでした。 それらのほとんどは単純に未完成です。 大丈夫のように思えますが、プログラマのダウンタイムを回避しましたが、これにより膨大な量の接続された資本が作成されました。 私たちはこれらのプロジェクトに多くの時間を費やして定期的に開発を続けていますが、主に「ここで何が起きているのか」を思い出したり、「新しいライブラリが出てきたためにこの部分を書き換える」または「改善することを学びました」と決めました。 現在、独自の製品を開発するときは、まず計画を実行し、必要なすべてのリソースを割り当て、プロジェクトが完了するまでその計画に従います。 また、開発者がダウンタイムを抱えている場合は、現時点で本を読むことができます。
これらのラインに達したすべての人に、私は行われた知的作業に感謝し、新しいアイデアのために私の心を大きく開けたいと思います。 世界は論理的であり、前提条件を正しく理解することしかできず、必然的な結果として、望ましい結果を達成します。