管理へのプロセスアプローチ：ファッションへのオマージュまたは成功への鍵？

システム理論は、プロセスをシステムの変化と見なします。 実際、アクティビティは結果を達成することを目的としたアクションであり、システムが新しい状態を獲得するという事実で表されます。 工学、技術、化学、さらには社会学のプロセスに遭遇します。 ただし、私たちはそれぞれ、毎日の作業プロセスに参加しています。 経験が示すように、多くの場合、企業の幹部はプロセスの自動化と形式化を避けていますが、これは非常に民主的な「ねじの締め付け」ではないようです。 しかし、無駄に。 あらゆるプロファイルの企業における適切な構築とプロセス管理は、責任と期限への注意により、従業員の適切な相互作用を確保するのに役立ちます。 プロセスアプローチは死んでいない-それは開発管理、会社、人員の多くのファッショナブルな理論の基礎です。 今日は、プロセスの発生場所、それらの管理方法、および原則としてそれらが必要かどうかを説明します。

プロセスアプローチ：サイバネティックスから管理まで

プロセス理論は、アクションの実行で構成される動作のモデルとしてプロセスを定義します。 原則として、プロセスは各アクションの実装の詳細（プロセスが属するシステムの動作）を知りません。 たとえば、ドキュメントを承認するプロセスで、会社は承認の条件と手順を定めましたが、プロセスはドキュメントがどのデバイスからどの地理的ポイントで調整されるかを気にしません。 プロセスのもう1つの重要な特性は、その制御性、つまり外部からの変更を受ける能力です。



一般に、CRMとERPについて言えば、誰もが「ビジネスプロセス」の概念を聞くことに慣れており、多くの場合、ビジネスプロセスとプロセスとの違いについて話し合います。 この用語は英語の「ビジネスプロセス」（ビジネスプロセス）からのトレーシングペーパーであり、複合語ビジネスは、企業で行われているプロセスを多数のプロセス（技術、化学、生物学など）から分離することを除いて、負荷がかかりません。 実際、このバージョンに同意するのは簡単です。たとえば、訴訟が単にプロセスと呼ばれ、サインを捨てる方法を覚えています。



Ruli24では 、プロセスの専門知識を蓄積してきました。実際、システム全体がプロセス管理システムであるため、プロセスまたはファッショナブルなビジネスプロセスのどちらを扱うかを決定することは非常に重要でした。 しかし、私たちには、これらの2つの概念の間に、サイバネティックスの限界の外側にある細い線がありますが、それは組織の理論によって記述されています：内部および外部の顧客に価値を創造します。 そして、ここでは、外部および内部クライアントの概念に背を向け、ラインが顕著になります。







ビジネスとは、商品の生産と販売、サービスと仕事の提供から利益を上げることを目的とした経済活動です。 しかし、すべてのプロセスが利益をもたらすわけではありません（研究、慈善、社会制度への支援）。 はい、結果（ニーズの満足）はありますが、利益はありません。 これは、当社のシステムがビジネスプロセスだけでなく説明することを意味します。



たとえば、Rule24プロセス制御システムのロジックを構築するために、プロセスを4つの主要なタイプに分離しました。 ビジネスプロセスに関する投稿でそれらについて既に言及しましたが、今度はビジネスではなく任意の会社のプロセスの観点から見てみましょう。 ただし、最も近い例である開発会社を使用してプロセスを検討します。 それは実際、私たちの実際の場合です。



研究プロセスは、情報源と議論を見つけることを目的としています。 このようなプロセスの結果は事前に決定されていませんが、達成されると戦略の基礎となります。 つまり、実際には概念です。 たとえば、開発会社（ベンダー）は、市場向けの新機能やソリューションのアイデアの検索を開始します。デスク調査、調査の実施、情報の収集、会議、ブレインストーミングの開始などです。 チームが新しいリリースに何を含めるかを事前に誰も知りません。 ただし、研究プロセスの最後に、特定の開発の概念が表示されます-それは同時にプロジェクトプロセスのエントリポイントです。



プロジェクトプロセスは、ネットワークスケジュールに従って作業を編成することです（バリエーションとして、これはガントチャート、スクラムボードなどです）。 この段階では、KPI、工数が計算され、総作業量が考慮されます。 結果が決定されます-これは製品です。 私たちの場合、開発者とデザイナーのチームは、厳密に段階と期限に従って開発を実装し始めます。 サブタスクの1つの期間のシフトの場合、プロジェクト全体の期限がシフトされます。



生産プロセスは、研究後の一種の分岐です。 プロジェクトとともに実行することも、プロジェクトの外部で実行することもできます。 事前定義されたルートを持つビジネスプロセスが含まれます。 これは、より「コンベア」モデルです。 たとえば、各新機能または製品の開発中に、標準テスト（回帰、機能、負荷、使いやすさ）に合格します。 それはむしろ製造プロセスです。



情報プロセスは、前の3つのプロセスと並行したプロセスです。 これは、ドキュメント、承認、人事アラートなどの処理です。 それは、善を生み出すすべての段階に役立ちます。



これらのプロセスはあらゆる組織に存在し、リソースと管理が必要です。 それらは、順次、並列、交差点を持つことができます。 いくつかの重要な目標を達成するために、社内のプロセスをデバッグすることが重要です。

• 自動化とリマインダーシステムによるルーチンタスクの精度と速度の向上
  
  
  
  
• プロセスの所有者、エグゼキューター 、プロセスの進行状況の監視における透明性を特定することにより、あらゆる段階で責任を拡大し、ヒューマンファクターを最小限に抑えます（たとえば、 Steering Wheel24などの自動制御システムで明確に確認できます）
  
  
  
  
• プロジェクト内の知識ベースとリソース管理の蓄積による最終結果の予測可能性
  
  
  
  
• プロセスの継続的な最適化とそれらの分離による継続的な品質管理と改善の作成
  
  
  
  
• 以前の結果の結果に基づいた適切な計画による、すべてのインフラストラクチャ要素とすべての従業員の関与。
  
  

最終的に、プロセス管理は最終製品のコストを削減し、リソースのリリースと再配布を節約し、会社の作業を透明にしますが、柔軟性を保持します-プロセスはいつでも変更できます。

重要な出発点：品質マネジメントシステムにおけるプロセスの場所（ISO 9001）

ISO 9000品質システム認証規格では、品質を達成するための最も重要な要素の1つは、作業のパフォーマンスに対するプロセスアプローチの原則です。 標準GOST R ISO 9001-2008の内容は次のとおりです。



「この規格は、要件を満たすことで顧客満足度を高めるために、品質管理システムの有効性の開発、実装、および改善における「プロセスアプローチ」の原則の適用を提唱しています。



運用を成功させるには、組織は相互に関連する多数のアクティビティを定義および管理する必要があります。 リソースを使用し、入力を出力に変換するように管理されているアクティビティは、プロセスと見なすことができます。 多くの場合、1つのプロセスの出力が次のプロセスの入力を直接形成します。

組織内でのプロセスシステムの使用とその識別および相互作用、および目的の結果を得るためのプロセス管理は、「プロセスアプローチ」と定義できます。

プロセスアプローチの利点は、システム内の個々のプロセスとそれらの組み合わせと相互作用の接合部で提供される制御の連続性です。



品質管理システムで使用する場合、このアプローチは次の重要性を強調します。



a）要件を理解し、満たす。

b）プロセスをその付加価値の観点から考慮する必要性。

c）プロセスの計画された結果を達成し、それらの有効性を確保する。

d）客観的な測定に基づくプロセスの継続的な改善。







図に示されているプロセスアプローチに基づいた品質管理システムのモデルは、プロセス間の関係を示しています（組織-約著者）。 このモデルは、消費者が入力と見なされる要件を設定する際に重要な役割を果たすことを示しています。 顧客満足度を監視するには、消費者が要件を満たしているという認識に関する情報を評価する必要があります。 図に示されているモデルは、この標準のすべての基本的な要件をカバーしていますが、プロセスを詳細レベルで示しているわけではありません。



したがって、標準では、組織がすべての主要なアクティビティを識別し、それらの管理方法を学習することを推奨しています。 また、リソースを使用して、目標と結果を持つアクティビティは、すでにプロセスと見なされます。 さらに、多くの場合、1つのプロセスの結果が別のプロセスのエントリポイントとして機能します。 GOST R ISO 9001：2008規格自体は、会社の重要な活動として、計画、リーダーシップ、管理分析、リソース管理（人員とインフラストラクチャを含む）、製品ライフサイクルプロセス管理、設計と開発、測定、分析、改善を示しています。

Rule24のプロセス-正しく操縦する方法

「すべてがプロセスです」-この位置から、Ruliシステムの設計時に進みました24。 企業の成長に関する投稿では、構造、商業化、法的形態に関係なく、あらゆる企業のプロセスの3つの主要なグループを反映したスキームがありました。

• 統治プロセス。 それらは、組織、リーダーシップ、管理の3つの要素に分類されます。 これらのプロセスでは、調整、分析、データ収集の有能なプロセスをプログラムで確立することが重要です。
  
  

これは、 ドキュメントを承認するプロセスがRuli24でどのように見えるかです 。各チェーンはアクションに関する通知を受け取り、ドキュメントを電子的に承認します。 同時に、人的要因が最小限に抑えられます。プロセスの所有者は、いつでもヒッチが発生したユーザーを確認してアクションを実行できます。 ちなみに、このようなプロセスはBPMN表記のルーラーで構成されており、ユーザーを設計者に任せるのではなく、クライアントのためにプロセスを正確、迅速に設計します。



すべての分析はレポートに組み込まれています。ユーザーは必要な選択を行い、フィルター、グラフィカル、表、チェスのような表現を使用してスライスを分析できます。

• 主なプロセス。 それらは会社の活動の種類に強く依存しますが、ほとんどの場合、マーケティング、供給、プロモーションが含まれます。
  
  

これらのプロセスの実装には、CRM、プランナー、カレンダー、ガントチャートなどの武器が必要です。 いくつかのユニットのアクションは調整され、最終的な目標に焦点を合わせる必要があります。

• サポートプロセスは、コアビジネスの直接的な生産と提供の要素です。 これには、人事管理、財務、セキュリティ、ITインフラストラクチャ管理、経理などが含まれます。
  
  

サポートプロセスは多数あり、主要プロセスと同じ人的要因を排除するような方法で構成することが重要です。 これを行うには、プロセスの相互接続を考慮して、会社の複雑な自動化を使用します。



この部門に加えて、研究、設計、生産、および情報プロセスに関する上記の部門があります。 それらは相互接続されているだけでなく、任意のオブジェクトまたはその一部に作用します。



Ruley24では、プロセス制御メカニズムには、指定された4つのタイプのプロセスに関する作業の編成が含まれます。 各プロセスには、独自の実行順序、管理フォーム、期待される結果があります。 プロセスの入力と出力は仕事です。



システムは、ジョブ管理のいくつかの形式を提示します。 いずれかの形式を使用するのは、さまざまなタイプのアクティビティの詳細と組織的な側面の両方によるものです。 情報処理の操作は 、管理フォームを使用して実行されます。

• 「着信文書」-外部着信文書の登録。
  
  
• 「送信ドキュメント」-外​​部組織に送信されるドキュメントの登録。
  
  
• 「リクエスト」は、関係の管理階層に関係なく、公式の通信のための普遍的なメカニズムです。
  
  

研究および検索プロセスとの連携は 、管理フォームを通じて実行されます。

• 「フォーラム」-チームワークの登録、内部ドキュメントの配布、ディスカッションメカニズム。
  
  
• 「会議」は会議の計画メカニズムです。
  
  

設計プロセスの操作は 、管理フォームを介して実行されます。

• 「サブジェクト」-フォームは、特定の領域での作業を強調するために使用されます。
  
  
• 「プロジェクト」-フォームは特定のプロジェクトの作業をグループ化するために使用されます。
  
  
• 「総作業」-一般作業の登録。これには、特定の出演者に割り当てられた作業が含まれます。
  
  
• 「プロジェクトの割り当て」-プロジェクト実行者への特定の割り当ての登録。
  
  

生産プロセスの作業は、管理フォームを使用して記録されます。

• 「ビジネスプロセス」-フォームの基本は、特定の結果を達成するための一連の作業の説明です。
  
  
• 「タスク」-公式な関係の階層に応じて、作業の編成と実行の制御が実行されるフォーム
  
  

前述のように、各プロセスの入力と出力は作業です。 各作品には独自のライフサイクルがあります。









次の機能を実行する過程で：

• 新しい作品の作成-結果として、「注意」状態の作品の説明を含むレコードがシステムに作成されます。
  
  
  
  
• 作業に慣れる-作業は「オープン」状態に移行します。
  
  
  
  
• 作業の実行-作業は「アクティブ」状態に移行します。
  
  
  
  
• 実行の事実の登録-作業の完了日と実行された作業に関するレポートが入力されます。 作業は「完了」状態に移行します。
  
  
  
  
• 作品を閉じる-作品の作者は作品の事実を確認し、「Closed」状態にします。 実行された作業の結果が満足のいくものでない場合、作成者はその作業を「終了（-）」状態にします。
  
  

ロシアの開発（およびCISの開発）に目を向けると、統合されたビジネスプロセスを持ついくつかの古典的なCRMに出会うことができますが、プロセスを管理および生産の各リンクのコンポーネントとして解釈するものはありません。 Ruli24の私たちはプロセスアプローチへのオリエンテーションから始まり、プロセスを独立したモジュールまたはファッショナブルな機能として実装しませんでした。



プロセスアプローチに関心がないために投稿を読んでいるが、CRMまたはビジネスのすべてのコンポーネントに適した自動化システムを自分で選択している場合は、ネタバレを見てください-Rule24インターフェースにはプロセスの実装が視覚的に表示されています。





従来、組織内のすべてのプロセスは、要件と顧客満足の間にあります。 そして、これはまさに商品（商品、仕事、サービス）を生産する主要なプロセスです。 クライアントの例を考えてみましょう。 冗談のように、「高級」パッケージには銀行があり、その中にRuli24があります。 銀行には、法人と個人の2種類の顧客がいます。 彼らは製品に要求をします：口座を開設し、操作を行い、預金をします。 サービスレベル、クライアントバンク、モバイルバージョン、ニュースレターなどを要求します。 銀行は要件を満たし、すべてのプロセスはRuli24システム内で行われます。会計から製品ポートフォリオの分析および内部チケットのシステムまでです。 同時に、すべてのプロセスが相互接続されているため、平均サービス時間が短縮され、ビジネス情報の収集が簡素化され、それに基づいて新製品の提供が形成されます。



しかし、会社のプロセス管理システムは、銀行などの機械だけでなく、ほとんどすべての会社にも必要です。 プロセスアプローチをより深く理解するために、いわゆるデミングシューハルトサイクル「Plan-Do-Check-Act」（PDCA）を適用できます。 これは「計画-アクション-検証-アクションの改善」です。 このサイクルを使用すると、組織の効率を改善することを目的としたプロセスの継続的な改善を常に実装できます。 このコンセプトは、 xRM Steering Wheel24の開発に深く反映されました。これが膨大な管理モデルの外観であり、システム全体の考え方の根底にあります。モデルをインタラクティブに想像すると、すべてのコンポーネントの関係と交差点が明確になります。







以下のプロセス説明フォームは、PERTダイアグラムに似ています。ネットワークスケジュール。違いは、「交差点」の条件に応じて、生産プロセスの特定の実装ですべての作業を実行できるわけではないことです。さらに、プロセスの説明の条件に応じて、各作業を（その属性の一部で）再定義できます。しかし、私たちが覚えているように、プロセスは内部のプロシージャと命令の実装については知りません。







そのため、モデルを決定し、貴社でのプロセス管理のためのおおよそのチェックリストを作成します。

• . , . , , , . .
  
  
  
  
• . , , , , . / . — , «»: , .
  
  
  
  
• — . , , , .
  
  
  
  
• (, , , ). .
  
  
  
  
• , . , 24, . , , . —«», .
  
  
  
  
• , , , . , . ( 24 ) , . , , .
  
  
  
  
• , , . , .
  
  

「今誰にこれを言っているの？私には小さなビジネスがあります、あなたの手のひらの上にいる人たち、どのようなプロセスです！」-おそらく、Habrの読者の一部はそのように考えるでしょう。私たちはあなたを保証します、あなたは間違っています。会社の経営は、その存在の最初の日からではなく、それを創造するというまさにそのアイデアの誕生から始まります。そして、この段階で最初のプロセスが形成されます。小規模で開始-主要な接続とアクションを自動化し、管理の成長とともに自動化を構築します。その後、会社が成長し、電話や顧客の流れが具体的になると、混乱や自動化の必要性がなくなります。結局のところ、同僚のcrmジョークが何度も冗談を言っているように、自動化された混乱は混乱のままです。