猫は死に、尾は剥がれた

猫は死に、尻尾は剥がれました-言葉がそれを食べると言う人は誰でも。 誰もがこの子供部屋を知っています。



しかし、今日はカウンターではなく、体系的な思考と、エンタープライズビジネスプロセスを理解するためのアプリケーションについてです。



プログラマーおよびCIOとして、私はしばしば幹部、工作員、経営陣の戦略的セッションなどのさまざまな会議に出席する必要がありました。



そこで彼らは皆、何かを言い、主張し、誓い、自分自身を提供し、他の人のアイデアを冒bし、攻撃し、防御し、泣き、笑います。 面白くて、時々怖くて、ほとんどの場合退屈に見えますが、最も重要なことは、ほとんど常に役に立たないことです。



原則として、会議の目的は、運用上の問題、戦術的な問題、戦略的な問題に関する意思決定です。 決定は、会議の結果、成果です。



しかし、これは不運です-ほとんどの場合、決定はまったくありません。彼らはただほつれ、会議を開き、胆汁を注ぎ、散らしました。 決定が下されると、通常は質が低下します。



興味深いことに、会議で決定が下されたとき、それは素晴らしいように思われました。 ソリューションが悪いことを理解するのは、後になります。 会議の直後、たとえば喫煙室で、時には決定がチームに発表されるとき、時には実装計画を作成するときに、しかしほとんど常にこの瞬間が来ます。 会議で決定が優れているように見える理由は、すぐに明らかになりました。 ここでは3つのシナリオが機能します。



最初のシナリオ



会議の時間が限られていて、モデレーターが眠らない場合、意思決定の目標は意思決定を管理することです。 これは成功基準です-成功したかどうか。 ソリューションの品質は、その通常の議論でさえ、議題にはありません。 決定が下されました-うーん、私たちはリーダーと呼ばれる無駄ではなく、私たちは仕事をしました。 はい、とても速いです。 一部の人は、このテクニックを使用してスピードアップします-立ちながら会議を開催します。 これは私たちの会社の特異性だと思っていましたが、判明しました-いいえ、新しく作られた知事の一部でさえ、この手法を使用しています。



第二のシナリオ



会議の時間が制限されていない場合、決定の目的は、この会議をすぐに終了することです。 誰もが自分の快適なゾーン、つまりオフィスや自宅に戻りたいと思っており、誰も何時間も座って鼻をかむことを望んでいません。 そのような状況では、大切な「友人、私たちは素晴らしい仕事をし、決定を下し、ありがとうございました」と聞くだけで、あらゆる質の決定が下されます。 そして、草さえ成長しません。



第三のシナリオ



人間の脳は、その発明を大いに評価するように配置されています。 意思決定者がこの会議で重要な重みを持つリーダーを思いついた場合、高い確率で彼はそれを拒否しないでしょう-単に彼がそれを思いついたからです。 ソリューションの品質も重要ではありません。主なことは、私がそれを思いついたことです。 悪魔の擁護者、ジンギスカンの方法、ガイド付きブレーンストーミングなど、この状況を克服するための多くのトリックがあります。それらについてはまた別の機会に説明します。



すべてのシナリオで、同じことが起こります-サロゲートによる結果の置換。 高品質で思慮深いソリューションは製品です。 決定を下すという事実は代理です。



あなたの会社と政府の両方で、サロゲートの多くの例を見ることができます。 通常、代理人は「ロードマップが形成された」、「手順が踏まれた」、「共通点が見つかった」、「解決策を決定することが決定された」などのフレーズで始まります。



私はこの状況を自分の利益のために使うことにしました。 プログラマーの心は、抜け道があることを理解しており、それは簡単でした。 さらに、適切なアプローチを見つけた場合、それはキャリアステロイドとして使用できます。これは、仲間のマネージャーと比較して重要な利点です。



そのような状況に最も適したfreymorkは、体系的な思考のように思えました。 簡単に説明します。 体系的思考は、すべての顕在化、特にビジネスにおける世界をシステム-人、プロセス、関係(形式的および非公式)、明示的および隠されたリーダー、物質的オブジェクト、情報システム、顧客、サプライヤーの複雑なコレクションとして考える抽象的な哲学です、機器など、無限に。



すべての要素を目の前に持っている場合、それらを知っているか、または¬–を参照してください。たとえば、すべてを1か所に配置します。これはシステムではなく、要素のセットです。 ほんの一握りの詳細。

このヒープからシステムを作成する方法は? そうです、オンにする必要があります-操作を開始します。



これは、プログラマーまたはエンジニアによく理解されています。 ここにプログラムコード、ここにコンピューターまたはサーバー、ここに処理のための入力データがあります。 ONを押します-システムは動作しています。 まあ、またはエラーがある場合は機能しませんでした。



人で構成されるシステムでは、通常、反対のことが当てはまり、この違いが重要です。 人々のシステムはあなたの前で働き、あなたの後に働きます。 しかし、あなたの存在下では、彼らはあなたと一緒には働きません。 実際、あなたの存在下では、それらはシステムではなくなり、再び一連の要素に変わります。 上記の例に戻り、システムのすべての要素とすべての要素を1か所で収集した場合。 あなたは何をしましたか? 右、システムをオフにしました。



システムのオンとオフの違いは何ですか? 人々は同じ、同じ位置、同じプロセス、同じリーダーが好きです-すべてが整っています。 システムのプロパティの違い。これは、「オン」になったときにのみ現れます。つまり、 システムが実行されているとき。 このようなシステムプロパティの例はどこにでもあり、簡単に見つけることができます。



電気のないテレビは電源を切ったシステムであり、画像を表示するという主な特性を示していません。 テレビの電源を入れます-画像が表示され、プロパティが表示されます。 動作中のテレビに水をかけると、気付かなかったシステムの新しい特性が表示されます。



このようなシステムのプロパティは、緊急、または発生と呼ばれます。



これらは、システムが組み立てられ、一連の要素から起動されるときに発生します。 両方の条件が重要です-それは組み立てられ、オンになっています。 私たちの場合、オフにならないとき。



タスクがその後システムを変更するためにシステムを理解することである場合、解決策は単純です-電源を切らずにそれを観察することです。



だから、「システム思考」フレームワークは私に言う-動作中のシステムを観察し、その特性、特に緊急事態を理解し、このシステムを改善するための力の適用点を見つけるでしょう。



もちろん、会議をオフにすることはできませんでしたし、意図していませんでした。 しかし、それはシステムの一部であったため、私は観察しませんでした、なぜなら 会議に積極的に参加しました。 フレームワークの重要なアプローチは、システムを理解することであり、システムを観察することであり、システムに参加することではありません。



私は思った-どのように私は会議と意思決定のシステムに正確に参加するのですか? 答えは、彼らが待たなかったところから来ました-映画「ファイトクラブ」から。 そこには、通常のコミュニケーションからの支援グループ(アルコール依存症、がん患者など)の違いを議論する場面があります。 そして、重要なフレーズが聞こえます:「人々はあなたが死にかけていると思うとき、彼らは真剣にあなたに耳を傾けます。 並んで話すだけではありません。」



私のミーティングへの参加は、私が何かを言ったときだけでなく、途切れることなく続きました。なぜなら、話す順番を常に待っていたからです。 私が何かを言うのを待っていました-自分の決定のバージョン、他の誰かの決定についての私の意見、「まあ、少なくとも何かを言って」。



彼らの発言の順番を待つことで、外出先でどれだけ答え、議論、反論を思い付くかについて、私たちはあまり耳を傾けずに掘り下げました。 時間と脳のリソースは、単に問題の解決策を生産的に反映するために残っていませんでした。



それにもかかわらず、観察を続けるために、私は簡単なテクニックを思いつきました-黙って。 意識的に、妥協せずに、そして最も重要なことには、当局の許可を得て。



一度にすべての会議に沈黙を導入することは不可能です-彼らは単に理解できず、キャリアステロイドの代わりに、キャリアポイズンが判明します。 したがって、私は徐々に沈黙を導入しました。



そのようなカテゴリがあります-リーダーが集まって、あまり重要ではない、またはまだ到着していない問題について話し合うための会議です。 私が始めたのはこれらでした。



ターンが来たとき、私は言った:「私は耳を傾けるが、私は電子メールで、会議の後に少し意見を述べる。」 オプションとして-同じトピックに関する次の会議で。 リーダーは驚いたが、同意し、私は黙って注意深く耳を傾けた。



通常の期待の緊張は完全に消えました。 議論の主題-問題-は私にとって本当に興味深いものになりました。 人々の意見はもはや敵対的ではありません。 あなたが何も言わず、主張せず、攻撃も防御もしない権利を持っていることを知ったとき、あなたは情報を聞き、掘り下げ、収集し始めます。



重要な条件は、約束の日、会議の後、何かを書くか言う必要があるということです。 しかし、これは非常に単純であり、興味深いものでさえあることが判明しました。 プログラマーの頭脳がシステムの変化の問題を解決するのを好むことはご存じでしょう。ビジネスは情報システムと同じ法則を持つシステムです。



それからもっと面白くなった。 ミーティング後に私が策定した決定は、会社の現実、リソース、能力を考慮に入れて、一桁優れたもので、考え抜かれました。 これは、私がとても若いからではなく、適切な場所で適切なタイミングで決断を下したからです。



もちろん、マネージャーは提案されたソリューションの品質に気付きました。 特に実装後、私はしばしば自分自身を引き受けました。 彼はこれが会議の沈黙の結果であることに気付き、私の沈黙を維持し始めました。時には私が沈黙することを強く勧めました。



ですから、彼と私だけが出席していた会議でもそうでした。 マネージャーが問題を話し、私を見て、思い出して言った-「ああ、すぐに答えないでしょう、私は手紙を待っています。」



私はこのアプローチをより頻繁に使用し始め、1つの問題が明らかになりました。 会議で私の「特別な」状況に気付いた同僚は、会議を妨害し始めました。 彼らの意見を尋ねられたとき、彼らは言った:「なぜ話して、彼は去って解決策を考え出すだろう、なぜ私はここにいるのか?」



仲間のマネージャーはビジネスプロセスの問題に関する貴重な情報を保有しているため、妨害行為の余地を残すことは不可能でした。 私自身でそのような情報を収集することは私にとって費用がかかりすぎて、全体の効果は無駄になります。



したがって、沈黙とトローリングのバランスを取る必要がありました。 会議とその問題が重要ではないことがわかった場合、ビジネスに大きな役割を果たさないでください。そして、私は黙ってはいませんでしたが、さらに何よりも言いました。 トロールの同僚は、問題についてのすべての知識を開示するように(良い方法で)挑発し、口論し、和解し、支持し、刺激を受けました。 一般に、私はいつも黙っていると思わないように、すべてをしました。



そして、このテクニックはうまくいきました-彼らは沈黙に注意を払うことを止めました。 いくつかは、それらを利用し始めました-彼らは彼らの問題をもたらし、提案された解決策でメールを受け取りました。 または、ITの能力の範囲内である場合は、決定自体。



そこで、キャリアステロイドが登場し、機能しました。コンピテンシー、機会、ITの影響範囲が成長しました。 ITは、ビジネスプロセスのリエンジニアリング、モチベーションシステムの開発、調達、生産、プロジェクト管理の手法の選択と実装など、一般的ではないソリューションを提供できるので、なぜですか。



もちろん、「会議を控える」レセプションには新しいことは何もありません。それは「良い考えはその後に来る」という表現の実践的な実装にすぎません。 しかし、うまくいきます。これが主なことです。



All Articles