ビジネスプロセスが怖くない理由

アレクサンダー・ボグダノフ（ AGIMA ）

実際、プロセスはそもそも人です。 おそらく、私のレポートでは、プロセスを自動化できるシステムについて少しだけ説明し、基本原則、これらのプロセスを構築する人々、およびこれらのプロセス自体が企業内で進化的に生まれる方法について詳しく説明します。



私の会社であるAGIMAの経験からお話しします。 自動化に本当に悩まされなかった理由、プロセス自体が生じた理由、自動化された理由、そして何らかの形ですべてがこの-私または管理チームへの特別な積極的な参加なしに構築された理由を説明します さて、私たちにとってそれが間違いなく大胆不敵な体験である理由をお話しします。













まず、私たちは10歳です。 とても幸せです。 実際、私たちが長い間存在するとは思っていませんでした。 それ以前は、すでに10歳の会社はありませんでした。 人生の1年か2年でいくつかの会社がありました。 10年は長い期間のように見えましたが、実際にはすぐに過ぎ去りましたが、振り返ってみると、あなたにとって多くの興味深いことがわかります。 一言で言えば、次のとおりです。







10年前には、4人の従業員がいて、1つの製品を製造し、1つのサービスを提供し、年間約100万ルーブルの売上高がありました。 そのようなチームを管理するには、何も必要ありませんでした。







私たち全員が同じ部屋に座っていて、お互いに直接コミュニケーションをとることができました。官僚的なコミュニケーション手段はまったく必要なく、彼らは私たちを妨害するだけでした。







6年前、すでに25人の従業員がいましたが、1つの製品を製造するか、1つのサービスを提供していましたが、売上高はすでに2000万人でした。発生しました。







しかし、原則として、平凡な管理システムで十分でした。 メーリングリストのレベルで特定のインフラストラクチャがあり、すべての通信はメールで行われました-クライアントと相互の両方で-すべてがメールで修正されました。 そしてそれでも、たとえばプロジェクトのワークフローがどのように行われるか、ある種のドキュメントをどこで入手するかなど、いくつかの一般的なルールが形になり始めました。 これらの一般的なルールは共通ディスク上に存在していたため、このシステムは非常に適していました。







3年前には60人の従業員がいました。 3つの方向がありましたが、それぞれの方向はプロセス間でわずかに異なることが明らかです。 そして約7000万ルーブル、年間売上高がありました。 この話を管理するのはもう少し難しくなりました。 そして、私たちは異なるウィキを持ち始めました。

• 最初のウィキは開発者にそれ自体で登場しました-開発者はプロジェクトの歴史を説明し始めました。 すべてのプロジェクトはそれぞれ長くなり、長くなり、知識を伝達する必要がありました。 その後、ウィキは経営陣に移住しました。 一般的に、ある時点で、wikiはフロントデスクからテストまでのすべての手順を吸収しました。 これですべてがwikiで行われます。
• 次に、会社の役割が登録され始めました。 原則として、社内の一部の従業員は非常に典型的な専門家であることをすでに理解しています。 私たちは、彼らがどのような役割を担うのか、およそどれくらいの費用がかかるのか、彼らが与えるべき製品の価格をどれくらい与えるべきなのかを説明しなければなりません。 そして、これらすべては、HRマネージャーから自動的に開始できます。HRマネージャーは、所定の役割を使用してそのようなスペシャリストを雇用し、これらの役割の実行方法を制御するという事実で終わります。
• さらに、従業員が何度も尋ねられる可能性のあるすべての質問に対して、自動的にFAQに入力しました。 それによりFAQを作成しました。
• また、一部のプロセスはすでにシステムを取得し始めており、ワークフローのドキュメントに反映されています-サイト制作プロセス、プロジェクト配信プロセス、ドキュメントフロー-すべてが自動的に修正されました。

現在、当社には120人以上の従業員がおり、原則として1社とは呼ばれません。すでに4社がある程度関与しています。 10の方向性と2億2000万を超える年間売上高があります。 もちろん、これは4社の会社を管理するのとはまったく異なる方法で管理する必要があります。







まず、企業文化のようなものがありました。 HRポリシーに関して、あなたの会社が他の会社とどのように異なるかを理解する必要があります。 特に、同じサイト構築に従事している企業だけでなく、他のことに従事しているがあなたの専門家に興味がある大企業とお金のためにすでに競争しているとき。 独自の企業文化を持ち、それを修正し、水をやり、世話をし、成長させて、人々が本当にあなたの会社、あなたのエコシステムに来るようにする必要があります。



各従業員が自分のキャリアラダーとは何か、一般的には将来何を待っているかを理解し、明確に伝える必要があります。 明確に定義し、詳細にする必要はありません。 一部の従業員の成績は非常に明確であるという事実にもかかわらず、すべての従業員が一生この場所に座らないという見通しは明確でなければなりません。



ほとんどすべての従業員について、モチベーションシステムをそれぞれ使用するのに便利なように修正する必要があります。システム内の何らかのリンクのモチベーションが出たら、対応する部門の長にそれを転送でき、彼はこのモチベーションシステムをどこにでも適用できますすべてが私たちにも固定されています。



もちろん、書類、大量のドキュメント、特にあなたがロシアでビジネスをするとき、彼らはすべてこれを非常によく理解しており、ドキュメントがたくさんあり、ドキュメントの詳細が大きいので、すべてを綴るべきです。



ある時点で、オフィスのインフラストラクチャの文書化を開始し、会議室の予約などからオフィスインフラストラクチャの使用を自動化します。 これはすべて、ある時点で交渉の順番があるときに自動的に行われます。 最初に、人々が時間を書く会議室に貼り付けられたリーフレットが表示され、次にそれが自動的にグーグル文書に入ります。ある時点でグーグル文書からBitrix24に移動します。







実際、成長が速いほど、変化も速くなります。 他は与えられません。 しかし、一般的に、私たち全員がどのように詳細に見えるかを伝える前に、多くの質問に答えたいと思いました。この急速な成長。」 したがって、私はあなたが急速に成長することができる方法を簡単に説明し、その後すぐにさらに変更する方法を説明します。







まず、成長を3つの大きな部分に分割しました。 まず、適切な受信ストリームを設定する必要があります。 リード、アプリケーションの着信ストリーム-何を呼んでも。







すべてが非常に簡単です。 それはすべてPRで始まります。 PRは私たちの市場で最も優れたツールだと思います。 さらに、多くの人が「私たちはまだそれほどクールなことをしていません。実際に何をPRすべきですか？」と尋ねます。 実際には、まずPRする必要はありませんが、PRには、独自のアプローチ、ビジョン、一般に哲学が必要です。これは、アイデア、使用したい新しいもの、信じているプロジェクトなどです。 d。 これは、最初の段階でPRに値するものであり、すでにかなり良いリードストリームを生成しています。 それは自動的に起こります-営業で、次に-生産で、そしてあなたは事例を生み出します。 実際、これはPRが生まれる絶え間ないストーリーであり、絶えずリードの流入ストリームを提供します。







2つ目は内部フローです。 3年前のある時点で、私たちは彼に再び焦点を合わせました。 これに先立ち、着信ストリームに多くの注意が払われました。3年前、彼らは内部ストリームに注意のベクトルをシフトしました。それは、より質の高いリードが生まれるからです。

ちなみに、 2015年と2016年のWhaleRiderカンファレンスで公開されているビデオを投稿しました。 YouTubeアカウントの 2015年と2016年のアカウントの関連シートを次に示します 。

内部フローは主にマネージャーによって制御されますが、私たちの場合、アカウントマネージャーにこの役割を与えました。これらは私たちのトップマネージャー、管理グループのリーダーです。 要するに、アカウントディレクターの仕事は、クライアントポートフォリオを維持し、このクライアントポートフォリオの管理スタッフを計画することですが、最も重要なことは、ワークロードを計画し、リードを獲得し、完成した注文を形成することです。 彼らは、クライアントと一緒にプロジェクトを終了し、このプロジェクトにPRを提供します。 さらに、私たちのプロジェクトのPR方法を見ると、私たちは常にクライアントと従業員をPRプロジェクトに関与させています。 いつでも実際のチームを見ることができます。 そして、私たちはクライアントを会議に連れて行き、彼らは私たちのプロジェクトについて話します。 実際、プロジェクトのコミッショニング中にクライアントに多大な注意を払うと、さらなるプロジェクトの非常に良い流れが生まれます。私たちはある時点で、私たちのアカウントディレクターが家族の父親家族である緊密な家族になります。 そして、これは、リードの一定した内部フローを生成するために非常にクールです。







私が言ったように、私はPRが絶え間ないリードの流れを提供するために不可欠なツールであると信じています。 そして、多くのPRと積極的なPRを始める前に、PR後に本当に質の高いリードを提供する唯一の方法は、自分が自分が特別だと信じていることを確かめることです。 自分が特別であると信じ、自分が特別である理由を理解する場合、何があっても、あなたは自分が一人でいると信じなければなりません。 そして、少なくともあなたの愛する人はそれを信じます。 その後、記事、さまざまなプレスリリース、Facebook、さらにはテレビセットなどのツールであれば、どのチャンネルを使用しても最大限のシーディングを行うことができます。つまり、ポジショニングはうまく機能します。







アプリケーションのキューを確保した後...キューは、作成できる以上のものである必要があると思います。 ちなみに、これは多くの人が論議している原則です。何がもっとあるべきか-注文または生産能力？ 私はあなたが作り出すことができるより多くの注文があるべきであるという支持者です。 ほぼすべての成功した製造および商社はこのように機能します。 良い車を買いに来ると、彼らは私たちを待ち行列に入れます。もちろん、この車が窓からのある種の車でない限り、私たちはこの車を待ちます。 そのため、リードストリームを作成した後、キューができ、そこから販売するものを選択できます。







私たちは自分自身に問いかけます：どうやってたくさん売ることができますか？ 先ほど言ったように、誰もがあなたに受け入れられる必要があるわけではありません。あなたができるよりもずっと長くするべきです。







どのようにラインナップと連携できますか？ 私たちのクライアントの入り口で、女の子が会います。 彼女の仕事は非常に原始的です-私たちのアカウントディレクターを降ろすことは、それが高価で非常に高い資格のあるリソースだからです。 女の子の仕事：最初に、私たちのところに来たクライアントまたはアプリケーションが必要な属性をすべて持っていることを確認することです。 簡単な説明が完了し、さらに作業を進めるために必要な資料、技術仕様などが添付されています。 まず、これはExcelで修正されました。 原則として、フローが小さく、キューが小さいExcelタブレットで十分です。複雑なツールを作成する必要はありません。 ある時点で、多くのリードがあったときに、このすべてをCRMに統合しました。



次は？ 少女がすべての申請を処理し、必要なすべての属性を備えた、私たちが作業する申請の一部が選択された後、すべてが当社のアカウントディレクターの輪で始まります。 会社には4人のアカウントディレクターがいて、各アカウントディレクターがマネージャーのグループを管理しています。 合計で、約25人のマネージャーが当社と協力しています。 各アカウントディレクターはリードを受け取ります。 すべての属性を持つクライアントが特定のプロジェクトを作成したいとします。 アカウントディレクターは見えますが、ポートフォリオとこのリードは現在の彼の状態に適合していますか？ はい/いいえ。 彼がそれを好まないか、それを服用したくない場合、または彼が今オーバーロードを持っている場合、彼はそれを服用せず、続けます。



4人のアカウントディレクター全員が合格すると、このリードはアフィリエイトプログラムを離れます。 以前は、これらのリードを破棄するか、長い待機リストに入れていましたが、現在はアフィリエイトプログラムに提供しています。 アフィリエイトプログラム-それは私たちにとってかなり楽しい発見でしたが、今ではおそらく最大のアフィリエイトネットワーク、すなわち 80のパートナー企業と80％のアフィリエイトプログラムにリードがあります。







アフィリエイトプログラムはシンプルに見えます。 アカウントダイレクターのおおよその承認サークルがある場合、それを受け入れますが、受け入れない場合でも、パートナーは同じ承認サークルを持ちます。 リーダーがアフィリエイトプログラムに参加するとすぐに、各パートナーは次のように言います。 そして、彼らが少し欲しければ、彼らはこのリードのために戦い、リードをさらに処理します。







私たちが選択したこれらのリードは、アカウントディレクターが引き続きリードするため、ルールがあります：常に100％勝つ必要があります。 アカウントディレクターであるあなたが突然、何らかの理由で入札に当たらないと思った場合は、入札に参加する必要はまったくありません。 したがって、一般に、販売といえば、現在の状態での販売は非常に高価な話であるため、この高価な話に負けることは多くのお金を失うことを意味します。



なぜ彼女は愛しいのですか？ まず、ほとんどすべてのトップマネージャーがセールに参加します。 さまざまな方向性のすべてのヘッド、すべて最大の専門知識を持っている人。 クライアントに来たら、私たちは完全に開かなければなりません、私たちのような人がこれ以上いないことを示さなければなりません-これが最初です。 第二-販売中に膨大な量のポリシーがあります。 クライアント側で誰がすべての会議に出席するか、誰が関係者であるか、どのクライアントの代表者が個人的および共通の利益を持っているかを明確に把握する必要があります。 次に、競合他社のどれがこの入札に参加しているかを把握する必要があり、その強みと弱みが何であるかを理解する必要があり、特定のケースで販売戦略を準備して、このすべての競合他社と比較して可能な限り自分自身を提示する必要がありますケース。 必要に応じて、必要に応じてプロジェクト分析を実施し、管理がクライアント側に足りないことを理解し、入札段階ですぐに彼を提供して管理を完全に引き継ぎます。 必要に応じて、必要な期限をできるだけ早く達成することを説得するために、彼の側に軍隊を上陸させる機会を彼に提供します。 販売プロセスは長く、長く、高価なので、勝つことが不可欠です。







概算の統計：現時点では、1か月あたり約200件の質の高い通話が含まれており、その費用は1か月あたり8,000万ルーブル程度です。 内部では、20％のみを受け取り、残りはアフィリエイトプログラムに割り当てられます。







たくさん売る方法を考え出すか、すでにたくさん売っていて、それで問題がなければ、ほとんどの企業が直面している段階に行き、多くはこの段階で死にます。



たくさん売ることはそれほど難しくありません。 大量に生産することは非常に困難です。 そして、先に行くほど、理解が深まります。 効率的かつ時間通りに大量に生産することは非常に困難です。 たくさん売る-問題ない。



それで、どれだけ生産するのですか？







まず、販売ラインナップと同様に、同じラインナップを生産する必要があります。 本番用のキューがない場合、全員がすぐにサービスを受ける場合、つまり クライアントは振り返り、明日、彼らは彼のプロジェクトを見始めました。それは、あなたが非常にうまくいっていないことを意味します。特に、おそらく、あなたは収益性で非常によくやっていません。 キューがない場合、ダウンタイムがあるためです。 ダウンタイムがある場合、お金を失っています。 それぞれの付加価値はそれほど大きくありません。ダウンタイムはすべての収益性を損なう可能性があります。 したがって、ダウンタイムは損失であり、ターンは利益です。 しかし、再び、キューを混chaosと混同しないでください。多くの人はキューの操作方法を知りません。



キューはどういう意味ですか？ クライアントは、自分のプロジェクトが実稼働に入る時期をすぐに理解する必要があります。 そして、多くの小さなトリックがあります。たとえば、私たちがチームを結成するのに1か月かかる権利を有する必要な条件を、ほとんどすべての契約で規定している契約でこれを行う方法です。 場合によっては、生産負荷に応じて、クライアントのニーズを満たし、契約に同意する前にプロジェクトのソーイングを開始できる場合があります。時には、作業を開始する前に契約に同意するためにアイテムを使用できる場合があります。 あなたには常にキューを管理する権利があります。 あなたの順番はa）でなければならない、b）カオスが発生しないように制御できなければならない。







では、契約を結んだ後、どのようにして生産を構築するのでしょうか？ まず、マネージャーはプロジェクト全体を各段階に分けます。 私たちが最初にプレートに持っていたこれらすべては、「出荷のプレート」と呼ばれていました。 契約が締結されました-すべてのステージは出荷プレートに含まれており、各ステージは行為により閉鎖され、各ステージには費用がかかります。 その後、プロジェクトがカットされるとすぐに、関係部門の各代表者、たとえば、設計、設計、開発の責任者は、それぞれがリソースを提供する義務があり、彼はプレートに直接表示する必要があり、実際に誰がこのプロジェクトに取り組む必要がありますか？ そして彼はさらに、この生産の収益性を同様に保証しなければなりません。



実際、コスト価格があるという結論に達しました。 この作品にはリソースがあり、これらの制作作品のコスト、つまりコストがあります。 そして、理解できる合計額、行為によってどれだけお金を受け取るかがあります。 つまり 各作品の収益性を自動的に計算できますが、最も重要なことは、収益性を計算するだけでなく、最も重要なことは各リソースのワークロードを計画できることです。 実際、このような話の後、プロジェクトだけでなくガントを導き出すことができますが、従業員ごとに、社内の従業員、外部の従業員などを確認できます。







一般に、ある時点で、リソースは非常に興味深いものであることに気付きました...私はリソースを、管理に関与していない、生産に直接関与しているすべての最終的な実行者と呼びます。デザイナー、デザイナー、開発者、テスターです。 リソースは非常に興味深いエンティティであり、多くの場合、時には非常に少数、より頻繁には非常に少数ですが、それは急速に成長している場合です。 ある時点で、あなたが突然成長しなければ、売上高と注文に落ちた場合、あなたはそれらの多くを持っています。 リソースが企業で最もスケーラブルなユニットであることがわかったとたんに、負荷が急に増加した場合...そして負荷が線形にならない場合、安定することはなく、常に低下または増加するため、一定の振幅になります物語。 一般に、リソースはこのストーリーに非常に迅速に適応する必要があります。 したがって、リソースにはいくつかの基準があります。

• 1つは、内部の定期的なリソースです。 すべての通常のリソースは常にフルタイム契約でサポートされるというルールがあります。 大まかに言えば、生産に直接関与するユニットが内部にある場合、クライアントが100％購入する必要があります。 これが最初です。
• 2つ目は、人員予備のような概念です。 これにも大きな注意を払う必要があります。 大ざっぱに言えば、私は常に競合他社の最も優秀な従業員のリストを持っています。私は非常に迅速にスケーリングする必要があるときに、どれが常に私の指を突くかを知っています。
• そして第三に、ある時点で、下請けの大規模なチームが必要であることに気付きました。

現時点では、下請け会社の連邦ネットワーク全体を4年間で作成し、80社が参加しています。 全体として、この下請け業者のネットワークにより、迅速に拡張できます。 描画すると、ダウンロードがどのように進行しているかを見ることができます（波の形で）。 内部リソースで常に最小負荷を提供し、すべての振幅をアウトソーシングでカバーします。 アウトソーシングマネーの収益性が低い場合でも、内部の人を維持する方が安くなると突然考えた場合、これらの振幅は、内部の人の単純な方法がこの収益性をすべて殺すことを示しているので、外部のチームで振幅をカバーする方が良いです。 しかし、ここでも、チームリーダーのすべての管理機能であるパフォーマーのみのアウトソーシングについて話しています。すべてが内部にあるべきです。







AGIMAでは現在、すべてがどのように管理されていますか？ ある時点で、誰かがそのようなシステムについて教えてくれました。私はそれを「バタフライシステム」と呼びました。







1つ目は、会社に存在するすべての専門知識です。 2つ目は、社内の管理チーム全体です。 彼らはお互いに従いません。 試験全体は、たとえば、分析部門の長、ユーザビリティ部門の長、設計部門の長など、主要な専門分野の長で構成されています。 . . -, PM ( , PM ). . , , - . . , , , . , , - PM' , -, .







«». «» – . , . – , . , , , , . «» :







, - , , , .. , . -, . - , , , , , - , , 3 , , . - – . - – , . - - .. , - – , . , , - , , . , , . . - – , , , -, , -, , . - , , -, .



, , -. ?







. 10- , . , . , - – . , , KPI – . : , .



?







-, , . , , 50-60 . . :

• Product Owner. , , .. , , . – , .. .
  
  
  
  
• - -, - , , - , – .
  
  
  
  
• , « ». , , SLA. : « , ». : « ». – , SLA , , , 15 , . , – . . , 250 15-16 . – , – – -, , , . , , , .

, , , , , , -. , , , « ». wiki. ..







, , . , – , , google docs, 24, . , , . つまり , , - . . wiki.







, , , , , , . . : , , NDA, wiki, , .. , , , workflow – . , , , , - .. , .



, - , IQ. .., . .







, , ? : , , , . . , , , … , - . , , , - .. つまり , , .







, 4 . , , – , , , , , , -. « ». 10 . . , , , – -, , , , , – . , . , , - , . , – ( , – , - ) , . , . , , : « , - , ». , , . , . , , , - , . つまり , , , .. , .



, , , : – , – . – .







, , . . , , , , , . , , . , - . , , , , , .. , , . , , , - , .



. , , , .







-, , .







, . , , , , . , , , - - , . , .. – - , – .







, , AGIMA.mobile AGIMA.mobile. . Agima.mobile/Gals, : , - - AGIMA?



, , . , . . , AGIMA.mobile , , : AGIMA.mobile – , , AGIMA? , ? つまり , . , , , . , , . , - , .







– , , , «», , , . , – . , – , . . , , , , , - , .







, , , , , - . - , , , , . , , -, , . , AGIMA, - . - , , . - , , , . , - .







, , . , , - , , , . , , , , , . – , .

— WhaleRider .



, , — WhaleRider 2017 — 5 6 .



, Ultimate Guitar, …



-- ,



! , , ( ) :

:

• — , ;
• ;
• KPI;
• (, ) ;
• 解散したQ＆A！

できません！これは機能しません！しかし、マイケルには鉄の議論があります-結果、うまくいきます！したがって、私たちは間違いなくミハイルに耳を傾け、会議で彼と議論します。