BPM (ビジネスプロセス管理) ツールを導入したい中規模企業向けのアーキテクチャをまとめています。これが役立つことは理解しており、導入したいのですが、アーキテクチャ内で適切な場所を見つけるのに苦労しています。
いつ、どのように BPM ツールを使用すべきか知りたいのですが、ビジネス プロセスとアプリケーション ワークフローをどのように区別していますか?
BPM (ビジネスプロセス管理) ツールを導入したい中規模企業向けのアーキテクチャをまとめています。これが役立つことは理解しており、導入したいのですが、アーキテクチャ内で適切な場所を見つけるのに苦労しています。
いつ、どのように BPM ツールを使用すべきか知りたいのですが、ビジネス プロセスとアプリケーション ワークフローをどのように区別していますか?
なぜBPMツールを導入したいのですか?バズワードコンプライアンスですか?アーキテクチャで場所を見つけるのに苦労している場合、ツールが大きな勝利をもたらすことはないと思います (少なくとも現在の理解では)。
アプリケーションワークフローツールは通常、特定のプロセスをモデル化し、半技術的なプロセス設計者にステップと相互作用を示す能力を与え、プログラマーが部分を実装するコードでスケルトンを肉付けできるようにすることに関心があります。個人的には、半技術的なプロセス リーダーをトレーニングするオーバーヘッドが、効果的なコミュニケーションとターンアラウンドで約束された利益を相殺する可能性があることを発見しました。結局のところ、プロセスを実装するコードを再生成するのは IT スタッフであり、提案された変更が技術面の問題のために元に戻されることがよくあるため、私は幻想と言いました (そのようなツールは、多くの場合、変更を実装するよりも提案する方が簡単です)。 )。
一部のビジネス プロセス管理ツールは、高価なアプリケーション ワークフロー ツールにすぎません。より高い視点を持ち、手動フローやその他の非 IT プロセスをアーキテクチャに組み込む人もいます (ただし、明らかにそのような手順は、実際には IT フローを出入りするためのスタブまたはゲートキーパーにすぎません)。あなたが中規模の会社を何と呼んでいるのか私にはわかりませんが、160 人の従業員を抱える航空宇宙工学会社で、やり過ぎだと評価した BPM ツールを見つけました。
悲しいことに、これは、すべての事実があっても、主観的な回答しか得られない質問の 1 つです (システム アナリストが異なれば意見も異なります)。簡単な概要が少なくともいくつかの助けになることを願っています。誇大宣伝に注意してください。そのようなツールは、特定のプロセス フローを持つ特定の組織でのみ価値があり、他の組織では妨げになることがわかりました。
企業が物事の流れのほとんどのケースを処理するプロセスを導入している場合は、現在のプロセスを調査するためのBPMツールを導入する時期になる可能性があります。ある意味、これは、しばらく前に尋ねられた「 BPMはあなたの心の中にありますか?」という質問を思い出させます。
正式なビジネス プロセスが既に確立されている企業に BPM を導入することは、より有用でやりがいのあることであることがわかりました。
アプリケーション ワークフローは、ユーザー インタラクション (ドキュメント、認証、署名など) のみを自動化するためのものです。しかし、ユーザーとシステムの相互作用に関して言えば、BPM は非常に便利です。
最終的なユーザーがアプリの実際の流れを見て理解できるようになるだけではありません (変更を行うために指を動かさないためです)。タスクの繰り返しや、システム間の複雑なやり取りを避けるためです。
もちろん、0 から始まるアプリでこれをコーディングすることはできますが、ビジネス プロセスが実際にサービスとして他のプロセスに使用される可能性がある場合、それは意味がなく、拡張性もありません。BPM スイートを使用すると、これを数時間で実行できます (実際には数回クリックしますが、顧客には伝えません)。
質問に戻りますが、BPM ツールの能力によっては、既にビジネス プロセスがあり、そのプロセスが異なる(これは重要です) 領域と異なるシステムのユーザー間の相互作用を必要とする場合、BPM を導入する価値があります。
インタラクションがより「人間中心」 (ドキュメント、承認など) である場合は、アプリ ワークフローで行います (または、既にツールを持っている場合は BPM をワークフローとして使用します)。
やり取りが同じ地域の複数のユーザーの間で行われる場合、またはデータが比較的簡単に消費され、誰もビジネス プロセスを気にしない場合 (つまり、誰がソーダを飲む番であるか) は、Web/デスク アプリをゼロから作成できます。
「いつ、どのように BPM ツールを使用すべきか」
Oscar Reyes は、投稿の最初の文で直接その点を指摘しています。プロセスビジョンが必要です。
BPM ツール (厳密には) は、ビジネス プロセスを管理するためのツールです。上記のゴデケの投稿の警告も正しいです。すべての BPM ツールが同じように作られているわけではありません。実際、BPM が実際に何であるかについて、誰にも同意してもらうことはできません。この用語は、ソフトウェア ベンダー、コンサルタント、アナリスト、報道機関など、さまざまな関係者によって奪われてきました (ほんの数例を挙げると)。
しかし、率直に答えると、BPM ツールは、ビジネス プロセスの一部またはすべてを自動化したい場合に適しています。注...すべてのビジネスにはビジネス プロセスがあります。すべての企業が文書化または管理しているわけではないというだけです。
BPM ソリューションにはさまざまな「タイプ」があるため、BPM ツールを実装する「方法」はコンテキストに依存します。大まかに言えば (これは議論の材料です)、BPM をトランザクションと人間中心のプロセスに分解できます。トランザクション BPM は、システム レベルのプロセス (主に統合) の自動化を目的としています。ここでは、SOA について多くのことがわかります。人間中心の BPM は、(明らかに) 人間の相互作用を伴うプロセス (主にドキュメントまたは構造化/非構造化データ管理) を対象としています。
「業務プロセスと申請ワークフローを区別する」
上記を参照。これは非常に一般的な議論です。また、BPM プロジェクトを適切に特定するには、事前に多くのことを行う必要があります。
最初の質問は、「当社は現在、プロセスごとにビジネスを管理していますか、それともそうしたいですか?」です。この質問に対する答えは、上から来るはずです。私の経験では、プロセス中心のビジネス管理に対するエグゼクティブ レベルのコミットメントがなければ、BPM プロジェクトはその目的を達成できない可能性があります。BPM ツールをインストールして、システムを統合したり、電子ドキュメントを管理したりすることができないというわけではありませんが、プロジェクトの ROI を逃したり失ったりする可能性が高いということです。
要するに、BPM プロジェクトにはプロセス中心のビジネス ビジョンが必要であり、それによって、そのビジョンをサポートする適切なアーキテクチャを定義するのにはるかに有利な立場に立つことができます。