統合-物語

カーン、あなたが顧客のビジネスプロセスに参入しておらず、ITプロセスでのみ掘り下げている場合。



この一般的なルールにはほとんど例外がありません。 多くの場合、IT構造はデータを所有せず、データがさらに必要な理由がわからないためです。 また、統合に関しては（デジタルツールを実装しないと、流行のチャットボットであれ旧式のCRMであれ）、これを非常に正確かつ詳細に理解する必要があります。



さまざまな話を見ました：実装後、FAXを操作するための1つの小さなサービスがウイルスのように振る舞い、メールサーバーや会社の他のサービスと戦うようになった方法（ちなみに勝ちました）、そしてセグメントがどのように「中小企業」中規模のビジネス（IT部門の驚いたことに）、および処理されたデータの意味とそれが必要な理由を人々が単に知らなかったということは含まれていませんでした-これはしばしば財政に関係します。



それでは、いくつかのITシステムを利用して接続するだけで何が起こるかについて、いくつかの話をしましょう。 ビジネス！

ロシアの理解における統合とは

最も一般的な例は次のとおりです。

• 既存のシステムから何かを取得する必要があります。 たとえば、サイトにはチケット予約システムがあり、空港には登録システムがあります。 それらを接続すると、オンライン登録を行うことができます。 当然、すべてがそれほど単純ではありません-実行中に多くの質問が発生します。
• 新しいものを接続する必要があります。 たとえば、インターネット銀行があり、銀行員向けの古き良きABSがあります。 実行層とインターフェース層を分離する必要があります。従業員が部門で行うことと、クライアントがインターネット銀行で行うことはインターフェースです。 ABSは、あるアカウントから別のアカウントへの転送を誰が要求したかを気にしません。クライアントはオンラインであるか、部門にいるのか電話であるのかです。 主なものは、操作が十分に許可されていることです。
• チェーンを構築する必要があります。 つまり、複数のシステムが全体として機能するため、たとえば、システムの1つで操作が開始され、2番目のシステムで継続し、3番目のシステムで終了します。 これが銀行振替の仕組みです。カードからデポジットに送金すると、通常、複数のシステムが同時にアクティブになります-デポジット、カード処理、モバイルまたはインターネットバンキング、SMSゲートウェイなどのABS

一般的なアプローチは、何らかの方法でシステム間のデータ交換を確立する必要があるということです。 これを昔ながらの方法で行うことができます。アップロードの交換やファイルの長距離での投げ出し、もう少し現代的な方法、Webサービスなどを使用できます。 重要なのは技術的な実装ではなく、一般的な原則です。 統合とは、企業のITシステムが特定のレベル以下のコストで動作する状況を意味します。 はい、祖母とフロッピーディスクを使って膝の上でそれを行うことができますが、祖母には孫や苗を植えるための太陰暦があり、ITインフラストラクチャは常に時計のように機能し、迅速に再構築され、ビジネスプロセスにブレーキをかけないことを忘れないでくださいこのインフラストラクチャが機能します。

これがすべてであり、適切な統合が必要です。



アプローチは異なります。 直接データ交換を使用することもありますが、多くの場合、インターフェイス（サービス消費者-Webアプリケーション、モバイルアプリケーション、パートナーシステムなど）とサービスプロバイダー（ABS、ERPなど）を分離します。 そして、たとえば、データ交換用のバスを構築します。 「祖母ファイル販売業者」を統合の最も古い技術として語るなら、バスを使ったアプローチはすでに産業時代です。 インターフェイスはデータをバスに送信し、バスはそれらを実行可能モジュールに運び、何をすべきかを「伝えます」。 途中で、データ形式または相互作用プロトコルを変換したり、データを第3システムから補完したり、異なるシステムでの操作を調整したりできます。その後、実行結果はインターフェースに戻ります。 このアプローチでは、任意の数のサブシステムに固執することができますが、最初の段階で実装するのはより困難ですが、多かれ少なかれ大規模な情報インフラストラクチャでは、再利用、信頼性、透明性、および他の多くの利点のために時間とお金を節約できるため、理にかなっています。



一度見たことがありますが、顧客は、お互いのデータベースに直接実行され、通常のデータ交換を行う5つのシステムの驚くほど安定した構成を持っていることがわかりました。 4年間、時計のように機能しました。 それから彼らはバスを作ることが可能であることを学びました、そして6つのバギーシステムがありました-5つの利用可能ともう1つのバス。 また、常に理想的なオプションとは限りません。 間違いは、バスに乗って、考えずに、直接データ交換をそのままバスに転送したことです。 彼らは追加の複雑さの層と障害点を受け取りましたが、それから何の利益も得られませんでした-アーキテクチャとプロセスをより正確に考える必要がありました。



純粋な形の現実の世界では、理想的なアーキテクチャは非常にまれです。 すべてを正しく構築し、時計のように機能するためには、まず次のことが必要です。

• 何が起こっているのかを理解する（そして、各部門は独自のビジョンを持つことになります）
• 最終的にビジネスに必要なものを理解します（つまり、全体像を見る人が必要です。ほとんどの場合、ITディレクターでさえありません）
• 人々が変化に抵抗している理由を理解し、システムにデータを共有させたくない（ほとんどの場合、誰かが盗むことができないか、誰かがコントロールを失う）

ここからが楽しみです。

プロジェクトの始まり

通常、顧客は真空状態では存在せず、何らかの統合が行われます。 つまり、何かがすでに機能していて、彼らはそれに触れないようにしています。 たとえば、コールセンターがあり、共通データベースから顧客データを取得する方法を知っています。 お尻を通して整理されていますが、整理されており、すべてがすでに良好です。 5年が経過し、サポートラインはこれを回避します。 その後、システムは新しい機能で成長し始めますが、これは実際には彼女のためではありません。 たとえば、企業のメッセンジャーに基づいて大きなファイルの交換が突然現れ、コールセンターのCRMに基づいて、ビジネス分析の構築を開始します（既製のモジュールの始まりがあり、すぐにそれを行うことにしたため）-そして、結果として、彼らはより多くのデータを転送します会社全体から、グラフを描くなどのために。 私の観点から、これは次のように見えます：

-皆さん、あなたはIT出身です。あなたは賢いです。 こんなにすごいことを迅速かつ安価に。

-これにはこのようなシステムが必要であり、簡単ではありません。

「さあ、すぐに盲目だ、これは間に合わせだ。」

そして、そのような一時的な小屋ほど永続的なものはありません。



その結果、顧客は約5〜7年に1度、新しい大規模システムを導入するか、完全に窒息する古いシステムを交換する必要があることを理解します。 レーキエラーの段階が始まります。



「月曜日からすべてが新しい」ということは決してありません。 多くの人々は、新しいシステムは誰もが平和に眠ることになると考えています。 いや 最初は、これらは多くの場合、万能薬ではなく、新しい障害点です。



ここでは、セクシーなインターネットバンキングの同じ導入を取り上げます。 これは、ABSの前面、つまり銀行の中核です。 ABS、クレジットオフィス、すべてのサブシステムを接続する必要があります。バスとインターフェイスが必要です。 最初は、「松葉杖で」荷を下すと成形されますが、銀行はあまりオンラインではありません。 次に、各フロントオフィスの操作を抽象化して、銀行の従業員が使用するシステムのAPIを作成し、このAPIをインターネットバンクに提供できることを理解します。 そして、そのときだけ、理解がやって来ます。なぜバスなのか。

交渉することを人々に教えます

上で言ったように、ビジネスプロセスに参加しないと、プロジェクトは運命づけられます。



以下に例を示します。最初はすべてが技術的なものです。 2つの部門、1つはデータが1C（会計）で処理され、もう1つはHRMS（人事会計システム）で処理されます。 200人の従業員がいる限り、すべてが正常でした。CSVをアンロードし、別のシステムにインポートし、給与を発行し、すべてを考慮に入れました。 6年後、従業員は1000人になりました。 人事部門の6人が手動でスクリプト測定を実行しました。 このスクリプトを書くようになりました。 簡単ですね。



人事担当者を1Cに異動させることは不可能です（より正確には、経済的に不合理です）-彼らのお尻は、他の部門の適用ソフトウェアではできないことを行います。 したがって、いずれかのシステムに基づいてマスターデータウェアハウスを作成することも、外部に作成することもできます。



そしてこの場所では、政治的争いがすでに始まっており、そのシステムがより重要です。 次に、誰がどのようにデータをアップロードし、どの形式で、どのエンコーディングでアップロードします。 ある会社の1251とUTF-8の間の壮大なホリバーは1か月間会議を行いました（これは別のプロジェクトにあり、通常はこのバスがこの問題を簡単に解決します）。



次に、どのデータ形式がユニバーサルであるかについて合意する必要があります。 ここでは、両方の部門がデータベースで必要なものと使用するものについて話します。 そうして初めて、彼らが正確に何をどのように理解するかを決めることができます。 このストーリーでは、インデックスストレージを使用しました。統合サーバーには、データベースのさまざまな部分（およびコンバーター）へのリンクがありました。ライブラリのカードインデックスのように、個別のデータレイクはありませんでした。



重要な点は、人々は自分たちの間で、どのデータ、どのように、どこで使用されるか、誰がそこに置くか、どこで、なぜかについて同意するということです。 もしそうなら-他のすべてはすでにテクニックです。 これが私たちが支援していることであり、既にビジネスニーズから技術的ソリューションが生まれています。



簿記と人事の例が抽象的すぎて単純すぎる場合、ある銀行が別の銀行を吸収する状況を想像してください。 接続して追加する必要があるものを考えて、さまざまなITシステムが連携し、部門が顧客が慣れていることをすべて実行できるようにします。 たとえば、このようなCIOの記録を読みたいと思います。 しかし、これはすべて通常ハードNDAの下にあります。

物語

最初の話は自転車ではありません。 全国の統合バスであるSMEVの進化をご覧ください。 これは、部門間のデータ交換です。 たとえば、パスポートを受け取ったら、証明書を収集して兵士を連れて行く必要はありません。 論理的ですね 州にはすべてのドキュメントがあり、システム内でドキュメントをリクエストするだけです。 しかし、ありません。 この話を知っている人-今ではSMEVに接続するのは非常に困難です。 なぜなら今では第三のタイヤの生まれ変わりが戦闘で働いているからです。 最初のバージョンはベータレベルでした。部門にどのような種類のデータがあり、それをどのようにアップロードするかを簡単に判断することを教えることは非常に困難でした。 第二に、多くが接続され、その結果、適切なレベルの抽象化なしに膨大な数の関数が現れましたが、それらは常に最適に開発されたわけではありません。 3番目のバージョンでは、ドキュメントを更新し、より多くのチェックと認定を導入しました。 これで、データはほぼ均一な形式でシステムに入力されます。



一般に、統合の一部はデータ、インターフェース、人、アプリケーションです。 アプリケーション-もちろん、これらはデータハンドラです。 たとえば、Ivanovに給与を支払う必要がある場合、プロセッサがこれを実行できます。 データは純粋な抽象化、つまり、イワノフを他の人と区別する方法、彼の給料などに関する情報です。 インターフェース-これは、たとえば、エンタープライズソフトウェアの人事マネージャーやXLSなどのコマンドの送信元です。 人々は、何かを望み、何かをする人々です。 彼らは通常見過ごされています。



別の例を示します。 彼らは、ある組織が顧客サービスを構築し、より多くを販売するのを助けました。 同時に、組織は若くなく、多くの情報システムとさらに多くのデータを持っています。 まず、この組織の顧客が誰であるかを理解する必要がありました。 同一人物がVasya Ivanov（またはデータがソーシャルメディアプロファイルからのものである場合は一般に「Fluffy Chepushila」）、Vasily Ivanov、VA Ivanov、または「passport number 1234 5678901」であることが判明する可能性があります。 最初に、ここに何人いるのかを理解する必要があります。それはまったく同じVasyaなのか、それともこれらのタイプミスなのか？ その組織には数百万の顧客レコードがありました。 スコアは、1人あたり5レコードでした。 彼らは、クリーニング、重複排除を行いました-1人あたり1.4レコードに削減しました。 古い台帳を含む、紙からは多くのあいまいなデータがありました-姓とイニシャルしかありませんでした。



多くの場合、顧客は何をどのように考えずに仕様を誤って入れます。 たとえば、1秒あたり約100トランザクションの要件がありました。 しかし、同時に、既存のシステムは1分あたり5レコードしか処理できませんでした。 彼らは拡大していると言った。 ハードウェア、ライセンスを変更し、インフラストラクチャを大幅に再構築する必要がありました。 1秒あたり約2レコード（1分あたり120）が必要であり、これは現在のハードウェアで最小限の変更で実行できることが判明しました。 そして、これは今後5年間の要件です。 数えませんでした-余分なお金をたくさん使いました。 私たちは尋ねます：彼らは言う、なぜ100トランザクション？ 彼らは私たちに説明します：これは特別なアナリストによって考慮されました。 後に試運転を祝ったとき、このアナリストは認めました。彼らはその数は美しいと言っています。



それ自体では、実装が長い間行われることはほとんどありません。 もっとデザインです。 この段階で、システムの所有者は、どのデータが誰かに開示されているか、データの責任者であり、どのような管理手順に同意する必要があります。 蟻の丘が展開し始めます-組織的にも心理的にも非常に困難です。 ロシアの人々は王だからです。「私は自分のシステムや外部からのデータを提供しません。さもなければ、彼らは私たちがうまく機能していないと突然言うでしょう。 欲しくありません。」 大きなリスクはありますが、永続性が適切に解決されます。



この段階でのほとんどの努力は、生存のための会議を必要とするかもしれません。 たとえば、ある企業で複数のサブシステムを組み合わせ、州の参加を得られるプロジェクトがありました。 また、一部のサブシステムでは、非常に長い間そこに住んでいた他の企業がこれを担当していました。 そして、自分のペースで働くことに慣れていました。 設計の最中に最悪の事態が発生しました。ある企業がその重要性を高めたいと思っていて、毎週会いに来ました。 6か月間、実装されたシステムの数値指標の違いはそれほど重要ではないという決定を下しましたが、このすべてが機能することが重要です。



または、ある銀行では会議のために全員を集めましたが、私の参加は明らかに約5分でしたが、結果としてマイナス3〜4時間でした。 実際、完全に過ごした1日であり、非常に残念です。 しかし、顧客が重要な場合、何もできません。



どのアプローチも標準化できると考えられています。つまり、アクション1、アクション2、アクション3を実行してファイルを転送する前に分解できる特定のタスクがあります。 そして、それのために既製のツールを選択するか、あなたが何をしているのか理解しているなら、あなた自身のものを書きます。 ただし、これを行うタスクを最初に理解する必要があります。 特定の統合問題に直面すると、特定の統合問題を解決します。



建設後、彼らは私たちをノックすることがあります。彼らは「あなたのタイヤが機能しない」と言います。 そうです、新しいエンティティが登場しました-それにすべてをもたらします！ そのため、適切なプロジェクトでは、専門家による監視システムが導入されているため、長い時間をかけて苦労して何がどこで落ちたかを理解できません。 そのようなツールは、どのサブシステムとどこが応答しないかをすぐに示します。 プロジェクトの1つでは、すべて同じように、最初のアラートはバスの責任者、つまり私たちによって受信されました。

-タイヤが機能していません！

-いいえ、ここでは機能していません。

-ああ、大丈夫。 リラックスしないでください。



または、ここに変更点があります。 8つのサービスがあり、1つのテスト日で合格する必要があります。 私たちの2つのモジュール、残りは他の会社によって書かれました。 土曜日のビジネスは、新しいシステムでの活動に「遊び」、モジュールを交互にテストします。 すべてが素晴らしいです。 土曜日は閉まり、夕方には全員が帰宅します。 切り替え。 これは正しいプロセスです。



別の銀行がこの経験を引き継ぎ、同じ方法でプロセスを構築しました。 完全なインフラストラクチャではなく、部分的にのみテストされています。 すべてを完全なプロセスに減らすことなく、モジュール間のリンクをチェックすることなく（より正確には、単純なテストのレベルで基本をチェックする）。 そして月曜日、切り替え後、特定の条件下でシステムの相互作用を確認するために、顧客の考えでは誰も来なかったことが判明しました。 つまり、彼らは個々のサービスをすべてテストしましたが、相互作用の方法はテストしませんでした、カール！ 彼らは要求をソーセージし始め、何かを送り、受け取り、何か他のものを始めます。 夕方、サブシステムの1つがデータストリームの作成を開始します。これにより、他のサブシステムが単純に過負荷になり、連鎖反応が始まります。 すべてが落ちています。



その理由は、包括的なテストを設定したり、包括的なプロジェクトを実施したりするためには、理想的には、単一のゼネコン、すべてを整理するか、自分で整理するよう依頼できる顧客が必要だからです。 あなたはそれを信じませんが、これは常にそうではありません。 多くの人々が金型から金型への統合を担当しているため、それが痛いときにいくつの問題があったのでしょうか。

データ付きブロードバンド

実際、私たちは翻訳者として働いています。 「これが必要です」と言うビジネスの顧客がいます。 誰も彼をこれ以上理解していない。 したがって、ビジネスの問題、目標、および願望は、開発者に伝えるために技術的な言語に翻訳する必要があります。 そして、開発者の問題をビジネスに伝えて、彼らのニーズを考慮に入れない場合、何が落ちるかを理解するようにします。 そしてまず、すべてをアーキテクチャに組み込む方法。ほとんどの場合、企業でパッチワークキルトが形成されるからです。ここに1つ、別の1つ、ここに3つ目があります。 これらは完全に異なる言語、異なるディレクトリ、異なるチームです。 しばらくの間、彼らは何らかの形でお互いに仲良くなりますが、すべての統合のタスクは、このブランケットからのすべての方向から来るデータでそのようなブロードバンド高速道路を作ることであり、誰もが理解しています：どこで、どこで、車とその理由。



最悪の事態は、IT部門とビジネスが異なる現実に住んでいるということです。 ITは、ビジネスにとって本当に重要なことを常に知っているわけではありません（たとえば、カットの直前に最適化する必要がある場合や、絶対に重要でない場合など、どの操作が最も価値があります）。 「サーバーを購入する必要があります。そうしないと、新年を生き延びることができません」-そして突然すべてが明らかになります。 それ以前は、「最大設計負荷」が休日のキューに関連していることを知らなかっただけです。 このような場合、IT言語をビジネスに翻訳し、お互いの交渉を支援できる人が必要です。



また、既成のシステムで誰かが静かに何かを変更するストーリーも大好きです。 新年の前に、彼にとって不必要と思われるエントリを削除することにより、「ディレクトリに物事を整理する」ヒーローが1人いました。 その結果、データが送信されなかったため、いくつかのトラックワゴンが税関で腐敗しました。 何が壊れているかはわかっていましたが、ルーターにアクセスできる人は休暇中です。 規制によると、彼だけがそれを行うことができました。 セキュリティルールに従って、部屋に入り、1つのロックを開き、次に2番目のロックを開き、サーバールームに移動し、セルを開き、そこでコンソールを開き、コンソールの情報を書き留めて、すべてを逆の順序で行う必要があります。



このように。 したがって、ITで何かを変更する場合は、まず会社全体で合意し、それを実装する必要があります。 そして合意に達するには、タスクが何であり、どのように行うかを理解し、すべての参加者が理解できる言語に翻訳し、すべての構築を支援する人々が必要です。 たとえば、理想的なシステムを設計するなど、作業の一部だけを実行しても、そのシステムを使用する必要があることを人々に納得させない場合、障害が発生します。



まあ、念のため、私のメール：AnIvanov@croc.ru。