実装のためのリソースよりも多くのタスクがある場合、タスクのキューは時間とともに増加し、それらのいくつかは安全に「愚か」と呼ばれます。

愚かなタスクとは、実装から期待される利点が必要なリソースの量を正当化しないが、顧客がその実装の必要性を主張する場合です。

ああ

• 開発タスクのフローの管理、
  
  「愚かな」タスクを取り除く方法は？
• 開発コストの管理、
  
  最も収益性の高いタスクを特定して選択する方法は？
• 限られたリソースの分配。
  
  リソースの量が同じままで、すべての顧客が満足していることを確認する方法は？

問題の本質とその原因

会社について簡単に説明し、状況の背景を示します。 活動の種類別-住宅ローン市場の規制機関。 産業-金融。 スケール-連邦政府。 ウラジオストクからカリーニングラードまでのアフィリエイトネットワークで、会社のITシステムを介してパートナーとやり取りする組織。 ITの焦点は、社内およびパートナー側の両方でビジネスプロセスをサポートする独自の企業情報システムの開発と改良です。 CISの開発予算は、年間1億ルーブルです。 KISは、年間600億ルーブルのビジネスをサポートしています。 CISユーザーの数-> 2000人。



入社当時、IT部門はビジネスプロセスを自動化し、すでにITソリューションでカバーされていたタスクを完了するための一連のタスクに長い間longれていました。

顧客（内部ビジネスユニット）の主な不満は、DITが非効率的に動作し、彼らが求めていることをしないということです。

同時に、顧客は40のリクエストの四半期に対して5つだけが作成されたという数字に訴えます。したがって、顧客ごとに、経理、財務、法務部、住宅ローン購入部....



しばらく働いた後、私はすでにこの状況を個人的に感じていました。 あなたは何か良いことをしようとし、それはあなたの顧客のために良いことをしようとしますが、最終的にはあなたはまだ彼にとって悪いです。

これは、効果的なプロジェクトマネージャーであり、「共有」では不十分な状況です。

タスクの大規模な流れの理由：

1. CISの開発に割り当てられた予算の量により、CISで多くを実現できます。
2. ExcelとAccessに基づいた多数のローカルソリューションが、CISの開発の方向性を決定します。
3. 各要求が実装されるという事実に慣れているユーザーと顧客。
4. DITの従業員。何をすべきか、彼らが何を求め、何をしようとしているのかがまったく同じであるという事実に慣れています。

図では、DITのディレクターの道徳的および心理的な状態を示しています。

ステップ＃1：ITリクエストの実現可能性調査の導入

ITソリューションの要求された開発/改良と実装のための実現可能性調査を導入することから始めました。



実行可能性調査は、タスクの複雑さの評価と予想される経済効果から構成されました。 実装の面倒さはDITによって提供され、経済効果の評価は顧客によって提供されました。 正当化は、どのタスクが自分自身をどのような期間回収できるかを示しました。





DITの提案で、会社とビジネスユニットの経営陣は、会社が経済的利益がないタスクにリソース/予算を費やさないことを決定しました。 問題の解決策が当社に著しい非経済的利益をもたらす可能性がある場合、これは理論的根拠に明記されるべきであり、これらの要求を承認する運営委員会の注意はこれに焦点を当てています。



パートナーの従業員はCISで働いていたため、パートナーのタスクの実装による経済効果も考慮しました。 当社にとっては、直接的な経済的利益はなかったかもしれませんが、このようにして当社との協力の魅力と収益性を高めました。 「1ルーブル」の最終決定を行い、200のパートナーすべてが経済的影響を受けました。



指定された決定は、付加価値をもたらさずにリソースを消費する、小さくて「愚かな」改善を伴う膨大なリクエストのストリームを無駄にするという事実につながりました。

従業員が手で何もしないように自動化できるすべてのものを自動化しようとした期間は終わりました。



実現可能性調査により、状況はDITのリソースが会社にとって最も有益なタスクとプロジェクトに集中しているという事実に至りました。 問題の最初の部分を解決し、リソースが効率的に使用されました。 2つ目は残った-DITが要求したことを行わなかったことに顧客はまだ満足していなかった。



この図は、実装のリクエストを選択する際の、DITのディレクターの道徳的および心理的状態の改善を示しています。

ステップ2：各顧客へのIT予算の割り当て

各ビジネスユニットは、達成する必要がある年指標（KPI）に対して設定されました。 これらの指標を達成するために、ビジネスユニットは必要なITソリューションを提供するためにDITへのリクエストを生成しました。 実行可能性調査の状況により、獲得ユニットのタスクはより多くのリソースを受け取り、サービス（支出）ユニットは「貧しい」親類の地位にいるという事実に至りました。



前者については、プロジェクトはより多くのお金を稼ぐことを目的とし、後者については節約することを目的としました。 自分の仕事の効率を高めたり、高めたりすることは、より多くを稼ぐ方法を決定するよりも収益性が低くなります。 これは、

DITはどのタスクを実装し、どこに予算を振り向けるかを決定したため、サービス事業部門のタスクを無視し、収益を上げる人のタスクを優先するというDITに対する告発につながりました。



一方で、すべてが秩序だったので、決定はすぐに来ませんでした。 リソースは、会社にとって最も収益性の高いタスクとプロジェクトに分類されます。 一方で、達成する必要がある指標を備えたユニットをセットアップすることは間違っていることがわかり、そのために必要なリソースを提供していないことがわかります。



彼らは、承認されたタスクの累積量に従って、ユニット間で予算を分割することにしました。 これを行うために、すべてのタスクの実装に必要なリソースの量を計算し、このボリューム内の各ビジネスユニットのタスクのシェアを決定しました。 これらの共有では、彼らは予算を「配布」しました。

DITは引き続き予算の責任を負っていましたが、今では各ビジネスユニット自体がどのタスクを、どの年間指標を達成し、割り当てられた金額を送信するかを決定しました。



そこで彼らは問題の第2の部分を解決し、ビジネスユニットが利用できる機会の範囲内でビジネスユニットが要求することを行いました。

何を得たの

1. 会社のビジネスにとってのメリットの観点から行うことが望ましいタスク。
2. 各ユニットのタスクの重要性を比較する必要なく、各ユニットのタスクとプロジェクトの実装を保証しました。
3. ビジネスユニットは、年間IT目標を達成するために予算を指示するIT要求の実装を独自に決定する機会を提供しました。
4. 1年間継続し、すべての最も重要なイニシアチブが実装されるように、ビジネスユニットでの予算支出を計画します。
5. 予算不足のため昨年実施されなかった、前向きな実行可能性調査を行った事業部門のタスクのリストに裏付けられた、会社のIT予算を増やす提案とともに予算委員会に行く機会。

図は「ハッピーエンド」です。

あとがき

ビジネスユニットは、フィージビリティスタディを必要としませんでした。興味を持っていませんでした。

最初に、彼らは彼らが尋ねたすべてを望んでいた。

次に、結果として生じる経済効果が確認されます。

このため、実現可能性調査は会社経営にとって理解可能であり、必要であったため、このツールは「上から」の決定に従って実装されました。

ビジネスユニットに明確な実行可能性調査を実施するよう指導するのに数年かかりました。



事業単位間の予算共有は、DIT内の組織の変更を伴いました。 各ビジネスユニットは、特定のプロジェクトマネージャーに割り当てられました。 その後、ディレクションヘッドの位置が紹介されました。 彼女の責任範囲には、ビジネスユニットのプロジェクトおよび非プロジェクトIT要求の予算とポートフォリオの管理が含まれます。

トピックに関する読み物

1. 注文する企業製造製品で注文のポートフォリオを形成するための戦略
2. Webスタジオの最適化。 サイトの生産における制限理論の適用
3. プロセスの定式化のためのシステム制約理論の適用

コメント内のトピックに関する「ケース」と既知のストーリーへのリンクを共有します。 これを行うことによって、あなたは私が収集するのを手伝うでしょう、そして、他の読者は練習の概要を得ます。



記事を読んだ後で、マイナスで私のカルマを邪魔したい場合は、記事にコメントを残してください。記事と私の性格があなたを傷つけ、好きではありませんでした。 今後、あなたの立場と意見を検討します。