負荷に対するビジネスプロセス

多くの人が「貨物のカルト」について知っています。これは、第二次世界大戦中に起こった驚くべき現象です。 戦闘中、太平洋の離島は突然戦略的標的になり、アメリカ人はそれらに軍事基地を建設し、地元の先住民は貨物飛行機を配達した文明の産物に満足しました。 原住民は、自分で物質的な価値を生み出さないcな白人が神から直接受け取り、神秘的な儀式を行うことを決定しました。パレードの地面で棒で行進し、アンテナのある箱の近くに座って、不可解な言語で祈り、天の鳥を呼びます。 戦争が終わったとき、アメリカ人は島と彼らの素朴な住民を去りました。 研究者が後に島に戻ったとき、彼らはパレードの地面で行進している塗装された縞模様のネイティブと偽のラジオ局の前で木製のヘッドフォンで「貨物」を要求するシャーマンを見つけて驚いた。



貨物カルトは、判明したように、遠くの島々だけでなく、ロシアの指導者のオフィスでも繁栄しています。 長年にわたり、彼らはスーツを着て椅子に座り、高価な輸入システムにお金をかけると鉄の鳥が飛び込み、ビジネスの効率が自動的に向上することを完全に確信してきました。 時には、さまざまなコンサルティング会社の名刺を持った木製のヘッドフォンの司祭も地平線に現れ、鉄の鳥を呼ぶ際にすべての可能な援助をします。



しかし、おそらく、叙情的なall話から脱線し、基本的なことを無視して自動制御システムの実装でさまざまな人々が同じ間違いを犯す方法と理由について話しましょう。 つまり、プロジェクトの顧客が自分のビジネスプロセスを見ることを拒否するのはなぜですか。



顧客の近視眼の最もひどい例から始めましょう 。それは最終的にプロジェクトに厳しいクリンチをもたらしました。 ある政府の顧客は、複雑な施設管理システムを望んでいました。 彼は、データ収集と管理の機能、サブシステムの詳細な要件を策定し、ビジネスレベルで一般的なタスクを形成（「これを改善」、「これを削減」）、文書化、信頼性などの要件を策定しましたGOST 34Xに完全に準拠しています。



請負業者はこれらの要件を受け入れ、システムの開発を開始しました。 初期のプロトタイプは顧客からの特別な苦情を引き起こさず、請負業者は引き続き開発を続けました。 すべてがシンプルで論理的でした。制御オブジェクトの画像が画面上にありました。 ユーザーはオブジェクトの状態を監視し、システムのさまざまな要素を選択し、それらに対して特定のアクションを実行できました。 技術仕様に厳密に従ってください。



最も興味深いことは、顧客が制御オブジェクトの操作に関する作業の組織について考え始めたときに始まりました。 彼らがどのように働くべきか、そして誰が何をすべきかについて質問し始めた人々がいました。 顧客が回答しなかった正しい質問。 そして彼は、多くのマネージャーに明らかな論理に導かれ、不幸なことにシステムを引き継いでお金で走る時間がなかった開発者の仕事を整理するために必要なすべてを「絞り出す」ことを決めました。



彼は新しいサービスの規制から始めました。 ため息のある請負業者は人々を実行から排除し、彼らを規制の開発に送りました。 彼は顧客と口論したくありませんでした。 その後、顧客は、人と人との組織的なやり取りは、自動化を必要とする非常に複雑なビジネスであると判断しました。 そして、彼は突然、開発中のシステムが相互作用のプロセスをサポートし、それらに柔軟に適応できるようになるといいと思いました。 しかし、それから物理学の法則が優勢になり、演技者は森に向かって視線を取り始め、食べられた前進を前もって嘆きました。



結局のところ、顧客はすべての「利点」を備えたビジネスプロセスの自動化を実際に必要としていた-自動ドキュメンテーション、グラフィックエディターでのルールの柔軟な構成、ビジネスルールに応じてリアルタイムで作成されるユーザーインターフェイス... TKの後ろに隠れますが、私たちの時代には誰が愚かな紙を気にしているのでしょうか？ その結果、顧客は大規模なトローリングを開始し、仕事の受け入れを遅らせ始め、請負業者は経済的問題に直面し、従業員は逃げ始め、プロジェクトは閉鎖の危機にonしていました。 ところで、成功したACS開発プロジェクト。



2番目の例はより穏やかですが、それ以上に明らかになっています。 大規模な商業顧客は、プロセス制御システムを望んでいました。 請負業者は専用のプラットフォームを使用して開発を開始しました。 調査中、実際には顧客にはプロセスがありませんでしたが、カオス的でけいれん性-けいれん性の性質を持つ、ある種の非公式な活動があることがわかりました。 また、ビジネスプロセスの形式化と定式化は作業の一部ではなかったため、システム開発者は脱出しなければなりませんでした。 彼らは頭を掻き、彼らの観点からプロセスの最も単純なバージョンを実装することにしました。 正式なプロセスを持っていなかった顧客は、頭をかいて、提案されたプロセスの形を取りました。



楽しさは、顧客の従業員がシステムを使用しようとしたときに始まりました。 プロセスは不快で、どこか複雑すぎて、どこか詳細が不十分な場所に設計されていることがわかりました。 それを実装するシステムも、顧客が期待したものとは完全に異なることが判明しました。 苦痛に満ちた研削の段階が始まり、無限入札中にシステムが必要な形を取り始め、顧客は自分のプロセスを構築して説明し始めました。 実装時間は2倍になり、両側のコストも完全にいサイズにまで増大しました。 プロジェクトはすでに純粋な原則から完了しており、次のステージの移行後、パフォーマーの疲れ果てたチームのほぼ全員が辞職しました。



3番目の例は成功例です。 顧客はビジネスプロセス自動化システムを望んでいました。 参照条件には、プロセス自体とその自動化システムの両方の要件が含まれていました。 プロジェクトの開始前に、顧客は主要なユーザーと実装チームのメンバーをトレーニングし、そこで予測されたビジネスプロセスの組織の原則、その利点を示しました。 ユーザー全体のなかで、何人かの熱狂的なファンが際立っており、顧客の側で実装チームの基礎を形成しました。



プロジェクトの3分の2は、あらゆる種類の指示、相互作用ルール、責任マトリックスなどの開発に関連していました。 システムのテストが開始されると、訓練を受けたユーザーと訓練されたユーザーがコンピューターの前に座った。 また、システムの機能はかなり貧弱であることが判明しましたが、すぐにきしむことなくプロセスが開始されました。 私の知る限り、コンサルタントの参加なしに、これまで（3年以上）正常に機能しています。



まとめると。 最初の例は、顧客の初期ニーズを評価する際の間違いを示しています。 経験豊富な実装者は、作業指示書を読むだけでなく、顧客のビジネスも確認する必要があります。 彼が説明されたプロセスを持っていない場合、彼の組織が将来のユーザーが働く部門をまだ形成していない場合、これは最初の警告音です。 遅かれ早かれ、そのような顧客は操作を整理したいと思うでしょう。 そして、彼があなたからプロセスを整理するためのコンサルティングサービスを購入しない場合（そして、これはほとんど常にそうです）、あなたはまだ、システムのアーキテクチャに実装中および操作中にプロセスの柔軟な調整の可能性を組み込む必要があります。 たとえば、SCADAシステムの代わりに、ESBベースのシステムまたはそれらの共生を実装します。 顧客にとって、これはプラットフォームと追加の容量の両方でより高価なソリューションになりますが、柔軟性にお金を払わなければならず、トラフが壊れてしまうリスクはアクションが必要です。



2番目のケースは、実際の状況から管理を分離する問題を示しています。 システムを注文するとき、彼らは部下を心から信じています。部下は、すべてのプロセスが長い間記述されており、何も発明する必要がないことを保証します。 その後、彼らは間違いを認めますが、これはあなたにとってそれを容易にするものではありません。 ここのレシピは、3ペニーのように簡単です。 プロダクションディレクターのオフィスから降ります。 パフォーマーの隣に座って、ピアとして彼らに話しかけます。 彼らはすべてのトラブルについてあなたに話します-そして、指示がなく、混乱が制御されていること、そして彼らが食堂で肉を報告しないことを。 それらに耳を傾け、「ビジネスプロセスの更新」という項目をオファーに含めます。 たぶんマネージャーは考えて、この仕事にあなたにお金を払うでしょう。 そして、それは正しいものに投資されるお金になります。



貨物のカルトはそれと何の関係がありますか？ そして、私たちは、それらの先住民のように、さまざまな「ベストプラクティス」、「ベストプラクティス」、鉄のカーテンが消えたために急増した奇跡的なシステムの波からまだ回復していません。 多くの人々は、システム自体がビジネス上の問題を解決すると信じています。 たとえば、ERPを購入すると、企業は在庫を削減し、CRMを実装することで、ダッシュするマネージャーによって顧客が奪われるリスクを即座に排除できます。



はい、鉄の鳥を呼ぶにはトランシーバーが必要です。 しかし、それが実際に届くには、まだ多くを知り、多くのことを考える必要があります。 問題の原因は過去にあります。 企業の舵を取るのは、技術的なメンタリティを持つ技術者です。 IT企業の大部分も技術者が率いています。 技術者は、技術、プログラム、アルゴリズム、システムの能力を信じています。 技術者は「紙片」を無視します：規制と指示。 そして、技術者は人をまったく信じていません。 しかし、人々はIT企業の主要なリソースであり、生産の主要な手段です。 人々は、自動化のレベルに関係なく、ビジネスプロセスの主要なギアです。 人々はプロセスにおいて無視されるべきではなく、プロジェクトの成功に対する彼らの影響を過小評価するべきではありません。 彼らがこれを理解しているプロジェクトは、チームの各メンバーのキャリアの装飾になります。



たぶん、同僚、私は再びいくつかの賞賛を述べました。 しかし、ビジネスからのこれらのネイティブと木製のヘッドフォンのシャーマンの友人が歴史にdrれるまで、私は卑劣で明白なことを言います。



09/23からのPS。 同僚は、 ミハイル・プリスの記事へのリンクを送信しました。「野望が壊れている、またはロシアでCIOの地位がキャリア行き止まりである理由」は、この投稿を完全に補完します。 追加するものはありません。 私は読み、丁寧に黙っています。