おめでとう。 問題、プロジェクト、予算、期限があります。 体を投げつけるのではなく、ソフトウェアが解決策ですが、今は構築するか購入するかを決定する必要があります。それが問題です。 またはそれは？ もはや明確な決定であるかどうかはわかりません。
社内プログラマーを雇って必要なシステムをコーディングし、購入して実行できる既製の製品を購入することを意味します。 これは、会計システム、取引システム、CRM、レポート、
レンディング、コレクション、CLM など。私たちは現在、何かを構築するのにコーディング経験を必要としないローコード環境に住んでいます。 ドラッグアンドドロップできます。 それを、非常にカスタマイズされた既製のソリューションを購入することと組み合わせると、次のようになります。
よくそれを構築しました。 では、建設するか購入するかの決定をどこで下す必要があるのでしょうか? 実際に必要なものを見てみましょう。
現在のシステムは、もはや単一のエントリ ポイントに依存することはできません。 クライアントの期待は、さまざまなチャネルが必要であることを示しています。 対面、直接電話またはコール センター、電子メール、ソーシャル メディア、SMS、Web、モバイル、タブレット – モバイル対応およびネイティブの両方
アプリはすべて、コンテンツやコンテキストを失うことなく交換可能である必要があります。 支店/店舗または対面で開始し、予約のために出発する必要がある顧客は、その日遅くにオンラインでログインしたときに、中断したところから再開できることを望んでいます。 また
彼らがオンラインで始めたが、不満を感じて助けを求めた場合、プロセスを最初からやり直す必要はありません。 これは社内関係者にも当てはまります。 組織内の情報チェーンは、クライアントが直面するのと同じくらい柔軟である必要があります
オプション。
では、どこからでもデータ入力を開始するには、次に何をすればよいでしょうか。 そもそも、そのデータが必要な理由があります。 新しいクライアントが組織と協力したい場合でも、既存のクライアントが新しい製品やサービスを望んでいる場合でも、日常的なクエリや苦情でもかまいません。
または情報要求。 これらはすべて、可能な限り効率的かつ簡単に要求を完了するために、定義された柔軟なプロセスを開始する必要があります。 プロセスは一般的に定義されており、通常、スタッフは一連のタスクに従って事前に定義された方法でプロセスを完了するように訓練されています。
特定のデータ入力に基づくアクション。
エンド カスタマーもシステム ユーザーも、情報がどこかで既にキャプチャされている場合、どこでもキーを再入力する必要はありません。 実際、情報が組織内のどこかで、またはデータ プロバイダー、信用調査機関などのサード パーティのソースから入手できる場合、
スクリーニングプロバイダーなど、プロセス全体で、それを必要とするすべてのユーザーがアクセスできる必要があります。 プロセスは定義されていますが、タッチポイントは全体を通して交換可能である必要があり、収集されたデータは可能な場合は統合され、可能な場合は構造化されている必要があります。
ドロップダウン メニュー、ルックアップ値、日付フィールド、制御された自由テキスト値により、データ品質を事前に確保します。 これにより、プロセス全体でより多くの自動化が可能になり、例外処理が少なくなります。
データがアクティブにキャプチャまたは更新される過程にあるので、人工知能を適用できます。 システムはポリシーコード化されたルールを使用しているため、スタッフはすべての詳細を知る必要はなく、新しいメンバーでもより複雑なケースに取り組むことができます。
スタッフが以前は広範なトレーニングと経験を積んで処理する必要があった決定を自動的に下すロジック。 必要に応じて手動で介入するための見落としや品質管理チェック、または完全な例外キューを許可しながら、ミスをなくすことができます。
これにはすべて、体系的なアプローチが必要です。 クライアントのポートフォリオのためにスタッフの引き出しにあるマニラフォルダーの古い考えは時代遅れであり、不必要なリスクを生み出します. 分離して処理されているクライアントは、制限と冗長の両方になる可能性があります
同時に。 法人顧客に他の複数のクライアントにまたがるディレクターがいる場合、個々のレビューが全体像を無視するのはなぜですか. また、すべての関係で同じディレクターを複数回レビューする予定ですか、それともできますか
組織全体でその情報を再利用できますか?
利益を明らかにするために、共通の関係者がいる必要さえありません。 類似の業界、類似のクライアントの顧客、クライアントのベンダー/サプライヤーもクライアントである場合はどうなりますか? これにより、情報をどのように処理する必要があるかがわかります
また、組織が最近ソフトウェアを検討する際に企業全体を見渡す必要がある理由についても説明します。 問題を個別に見て、それをそのように扱い、予算を設定し、CRM、金融犯罪、クライアントへの支援のコンポーネントごとに RFP を発行すると、最終的には
すべてを統合しようとして、当初期待されていた潜在的な節約よりも多くのリソースを費やしています。 個別の予算と監督を受ける可能性のあるすべての地域または事業部門にこれを適用すると、最終的に 8 つのバージョンが作成されます。
領域ごとに大幅なカスタマイズが行われるため、それ自体と統合する必要がある同じソフトウェアの、達成できる規模の経済が失われます。
毎年または別の方法で見直す必要がある引き出しの中のフォルダー。スタッフは何をいつ行うべきかをトレーニングする必要があります。 レビュー全体（または新しいオンボーディング/追加の製品/サービスなど）は、複合部分に分解できます。
他の人/チームが処理することはできません。 その後、システムは、タスクがいつ完了したか、または入力のために次の人に送信するのに十分なデータがキャプチャされたときを判断できます。 これらはすべて、ケースとサブケースとして構造化されています。 このように各要素
ケースには、独自の期限、エスカレーション パス、担当者、および承認者を設定できます。 スタッフ メンバーが完了する方法とその中のさまざまな要素について誰に行くべきかを知るのに十分な経験を積む必要がある XNUMX つの大きなタスクの代わりに、システムが作業を割り当てるようになりました。
意思決定者が重要なことに集中できるように、できるだけ多くのタスクを自動化して、会社全体でタイムリーに完了できるようにします。
これは、ビジネスの観点からはすべて順調です。 仕事が分かっていて、何をする必要があるか。 しかし、ソフトウェアを自分で購入するか構築するかを決定しようとするとき、それはどのように考慮に入れられるのでしょうか? 複数のソースがあると仮定しましょう
複数のシステムにわたるデータの。 最新のシステムはすべて、API 駆動であり、ローコード/ノーコード機能を備えていることが期待されています。 より高速で柔軟なソフトウェアのための合理的な仮定。 最近のあらゆるものは、回避するために一種のマイクロサービスとして扱う必要があります
古いスタイルのソフトウェア モノリス。 ソフトウェアは、必要に応じて変更に適応できる、入手可能で将来的にも最適なソフトウェアであるため、インストールして使用する必要があります。 難しすぎて時間がかかるという理由だけで定着し、維持されているオファリングが多すぎる
交換する。 これのほとんどは、ルールがハードコーディングされており、おそらくデータ自体に絡み合っているためです。データは統合されるだけでなく、情報チェーン内のソフトウェアの個別の部分ごとに複数回複製されます。XNUMX つの部分を置き換えようとすると、
システム全体が壊れる可能性があります。 古い思考プロセスが多すぎます。壊れていない場合は、修正しないでください。 本当に必要なのは、これらすべてのコンポーネントがマイクロサービスであり、必要なデータを取得し、自動化されたルールまたはユーザー入力/レビューを適用し、
それを次のマイクロサービスに渡します。 データは複数の場所に保存しないでください。 フェデレーションされている可能性がありますが、バックアップの外部では複製されていません。 CRM、オンボーディング、KYC、クライアント アウトリーチなどのシステムは、必要なデータのみにアクセスし、アクセスしないようにする必要があります。
選択した場合を除き、データ リポジトリ自体になります。 同じデータを複数の場所に複製し、それを管理するルールを適用することは、余分なシステムが追加されるたびに関連する複雑さが増していくため、無駄な作業です。
これにより、最終的な検討が行われます。 単一の信頼できる情報源/ゴールデン コピーがある場合でも、複数の冗長で競合する記録とそれらを更新できるシステムがある場合でも、次の行に基づいて要件の別のレイヤーにいることに気付くでしょう。
ビジネス、管轄、クライアントの種類、および製品/サービス。 個人は、企業または信託とは異なる扱いを受け、消費者/小売業、商業または企業の事業分野によって、要件と適合性が異なります。 最も基本的な例では、
当社には 10 種類のクライアント (個人 – 独身、既婚者など、非公開会社、公開会社、信託、慈善団体など) がおり、10 の地域で事業を展開し、10 種類の製品/サービスを提供している可能性があります。潜在的に 1000 以上のルール
適用されます。 地域、事業部門、クライアントの種類、製品やサービスのルールを定義し、代わりにシステムに要件を解決させる方がはるかに簡単ではないでしょうか? 重複を削除し、以前にあったデータ ポイントを再利用する
提供された。 これは、プロセスとルールをデータ層から抽象化する利点です。
したがって、ソフトウェアの購入または構築に関する古い問題を考えると、オムニチャネルのオーケストレーション、可能な場合のプロセスの自動化、柔軟なルール ロジック、監視と監査可能性のためのケース管理、ローコードと API ドリブン、抽象化が必要であることがわかります。
データ レイヤーと、さまざまなロジック レイヤーから継承できるインテリジェントなルール エンジン。 テクノロジー市場には、考えられるあらゆるニッチな問題を喜んで満足させるイノベーターがたくさんいますが、どの時点で「既製」の意味がなくなるのでしょうか。
自分で構築するのではなく、すべてカスタマイズして相互に統合する必要がある製品。 ローコード プラットフォームでは、要件の 80% を利用でき、そのデルタ 20% を構成するだけで済みます。 両方の長所は低い
他の人が再利用可能なコンポーネントを構築したコード プラットフォーム。これにより、ビジネスのアクセラレーターとして「既製の」製品を入手できると同時に、スタッフまたは認定されたサード パーティが要件固有の残りの部分を構築することもできます。
あなたの組織に。 買うか作るか？ 本当は両方あるはずです。
