道を知ることと道を歩くことは違う
これはまるで SF の仕掛けのように聞こえますが、過去 5 年間、岩の下に隠れていた人々にとって、これは実際には、古くてばらばらの手動プロセスとレガシー システムを、万能のデジタル ソリューションに変えるプロセスです。すべてを 1 つのパッケージにまとめ、全員が調和して作業できるようにし、プロセスの問題をすべて解決します。
少なくともそれが夢です。
それほど単純なことはめったになく、完了することはさらにまれです。これは、ビジネスにおける問題点を見つけ、時代遅れのプロセスを修正し、システムを置き換えたり削除したりしながら、到達不可能と思われる目標に向かって歩み続ける継続的なプロセスです。
絶望的に聞こえるかもしれませんが、実際はそうではありません。これは素晴らしい挑戦であり、すべての企業が目指すべきものです。過去 10 年間に設立された企業は、すでに有利なスタートを切っており、ほとんどが統合システムで運用されています... しかし、通常は財務部門に、Sam がコア プロセスを管理するために巨大なスプレッドシートを作成している暗い隅が常に存在します。私たちはあなたを見ている、Sam。あなたは隠れることはできません!
それで、次のような疑問が湧いてきます。これはローコードとどう関係があるのでしょうか?
無視するのは簡単
ローコードがデジタル変革を実現するのに役立つ方法は数多くありますが、そのほとんどは、現在の状況を理解することから始まります。ビジネスのアーキテクチャの状態は、主に次のカテゴリのいずれかに当てはまるでしょう (ただし、その間にはさまざまなグレーの色合いがあります)。
- まっさらな状態 – 文字通りデジタルシステムはありません。新しいビジネスかもしれませんし、スプレッドシートはいくつかあるかもしれませんが、大規模なアプリケーションはありません。
- コアシステムとサポートアプリケーション - 1つのメインシステムと、統合または分離されたシステムがいくつかある
- あらゆるものが、あらゆる場所で、一度に – コアシステムがあるかどうかはわかりませんが、明確なアーキテクチャはなく、誰もがさまざまなアプリケーションを購入して、さまざまなこと、さらには同じことのいくつかを実行しています。
私の経験では、3 番目の状況は必要以上に一般的ですが、2 番目の状況は現代の企業のほとんどが陥る状況だと思います。最初の状況に陥った人は、おそらく最も簡単な仕事に就いているでしょう (スプレッドシートの数式を解読しようとすること以外では)。
ここでは、典型的なユースケースの状況を想定し、大量のデータを保持する何らかのコア システムがあるとします。このシステムは、コア データをうまく保存し、そのデータの使用と保守のトレーニングを受けた少数の主要ユーザーをサポートしています。ただし、コア グループ以外のユーザーにとっては、データにアクセスするのが簡単ではなく、他のいくつかのシステムからデータを取得する必要がある場合もあります。これらのサポート システムの一部は、コア システムからデータを取得する可能性もあります。これらのシステムは、REST API や SOAP やフラット ファイルなどの古いモデルと最新の方法で統合されている可能性があります。
また、コアデータ用のモバイル サービスが提供されていない可能性も高く、そのため人々はどこへ行くにもラップトップを持ち歩くか、ファイルを印刷して持ち歩く傾向があります。
その上、シャドー IT の層があります (財務部門の Sam のような人、Sam さん、あなたのことも忘れていません)。これらは通常、独自の複雑なスプレッドシートを作成したり、独自のアプリケーションを購入したりしている技術に精通したユーザーです (おそらく IT 部門に相談せずに)。私と同じくらい長く IT に携わっている人なら、ビジネスにおける Access データベースの脅威を覚えているでしょう。一部のデータベースは非常に大きくなり、稼働し続けるために誰かが数千行を削除するのが毎日の作業でした。
おそらく、企業はこのような無知な状態で永遠に運営されてきたのでしょうが、進歩的な人物が現れてデジタル変革を開始しました。今、あなたとローコードはソリューションの一部となり、企業がより効果的かつ効率的になるよう支援することになります。あなたは何をするつもりですか?
何でも可能な世界
多くの場合、ビジネスにローコードを導入する際の最適な開始点は、すぐに目に見える価値を追加できるものを素早く作成することです。新しいローコード プラットフォームの利点を明確に示すもの、つまり、高速で大きな効果をもたらすもの。多くの場合、これを行う最適な方法は、何らかのポータルを使用することです。バックオフィス、顧客対応、モバイルなどです。
先ほど、コア システムは熟練していないユーザーにとってアクセスしにくいことが多く、情報を見つけるのが困難であると述べました。また、重要なデータが複数のページや複数のシステムに分散していることも多々あります。つまり、たとえば顧客のデータにアクセスしたい人は、多くのページや複数のシステム (コア発注システム、CRM システム、配送管理システムなど) にアクセスして調べる必要がある場合があります。このデータを一元化された読み取り専用のバックオフィス ポータルに表示することは、利用可能な統合オプションによっては簡単なプロセスになる可能性があり、特定のビジネス プロセスに合わせてデータへのアクセス方法を最適化することで、人々の時間を大幅に節約できます。
そのとき、アプリケーションが実際に完全にレスポンシブであり、モバイル デバイスからアクセスできることを示すと、本当に驚かされます。アプリケーションにモバイル ビューを追加して、スマートフォンやタブレットで表示できるようにするのは簡単なプロセスであり、外出中にこの情報にアクセスできることは、通常、ユーザーにとって大きな進歩です。
もう 1 つの選択肢は、顧客ポータルを作成することです。おそらく、あなたのビジネスは顧客中心ですが、顧客は現在、コア システムの一部として提供されている古い Web サイトを通じて情報にアクセスできる範囲が限られています。その場合、カスタマイズはおそらく難しく (コストもかかります)、顧客が見たいと思う情報のほとんどが実際には含まれていません。
モダンで洗練されたポータルで巧みに作られた顧客体験を簡単に作成できます。 Mendixまた、現在のサービスに対する満足度が低い場合や、満足度が低い場合に、顧客や企業に良い感情を抱かせるための優れた方法にもなります。
ポータルを構築している間、常に「次は何だろう?」と自問する必要があります。現在のアプリはどこまで進化すると思いますか? 完成するアプリケーションはほとんどないというのが私の意見です。常に改善や強化が必要です。私は、こうした点を念頭に置き、アーキテクチャの目標に合うように構築することを好みます。このシステムは、新しいデジタル ランドスケープのハブになりますか? そうでない場合、そのハブにはどのように接続しますか?
ドアを案内することしかできません…
会社にローコードを導入する際に、ローコードのメリットをビジネス全体に説明しなければならない場合があります。技術系の人は、従来のコードではなくローコードを使用するメリットをすぐに理解できるかもしれませんが、ビジネス系の人は「アプリケーションの構築が速くなります」という程度で終わってしまうかもしれません。この発言は真実ですが、それは真実の一部に過ぎず、ローコードのようなプラットフォームがもたらすメリットのすべてを正確に示しているわけではありません。 Mendix ビジネスにもたらすことができるもの。
デジタルトランスフォーメーションの一環として、「シャドーIT」を根絶し、明るみに出すことに重点を置く必要があります。これは、財務部門のサムのようなパワーユーザーが、 Mendix 始めるのに必ずしもプロの開発者を必要としません。Studioを使用すると、Excelスプレッドシートをインポートしてアプリケーションを作成したり、サポートなしで1つのフォームシステムを作成したりできます（ Mendixのトレーニング パス)。
この時こそ、コラボレーションのメッセージをはっきりと伝える必要があります。そこで、組織内のプロの開発者に連絡してサポートを受けることができることを理解してもらう必要があります。 Mendix プラットフォーム。これらを組み合わせることで、より高度なソリューションを作成できます。膨大なスプレッドシートや、企業が別の既製ソリューションを購入する必要がなくなります。
構築されたものはすべて Control Center から制御できるため、不正に数百のアプリケーションを公開してしまう心配もありません。また、社内 Marketplace の共有モジュール、企業専用のモジュール、DataHub を通じて共有される簡単にアクセスできるデータ ソースでサポートすることもできます。
赤い錠剤を飲めば、不思議の国に留まれ、ウサギの穴がどれだけ深いかお見せします
この変革の過程では、誰かがデジタル環境全体を計画する必要があります。次のことを見つける必要があります。
- 会社内のすべてのアプリケーション (Office などの標準ソフトウェアを除く): このステップの主な目的は、特定の問題に対処するためにビジネス チームが購入したアプリケーションを見つけることです。これにより、システム内の機能が重複している可能性があり、ローコードで簡単に置き換え可能なものを特定できます (プロセスでライセンスの費用を節約できます)。
- システム間の統合: API またはフラット ファイルによってデータが 1 つのシステムから別のシステムに転送される場所では、特に弱点を強調して注意する必要があります。
- 発生している可能性のあるデータの重複: これは、誰かが 2 つのシステムにデータを入力するという単純なものから、重複するプロセスという複雑なものまで考えられます。すべてを 1 つの真実のソースに合理化するか、可能な限りそれに近いものにする必要があり、同じ質問を 2 回行うことはありません (もちろん、プロセスで確認が要求されない限り)。
次に、ランドスケープをどのようにしたいかを示す新しいマップが必要になります。これにより、冗長なシステムとデータが合理化され、統合レイヤーが最適化されます。
すべての新しい開発は、新しいマップ上にホームを持つ必要があり、できれば古いマップの一部を置き換えるか、組み合わせる必要があります。
すると、新しいアプリケーションを作成するサイクルに入り、同時に既存のアプリケーションの変更要求やバグも管理することになります (これは誰にでも起こり得ることです)。これらすべてを管理するには、バックログを注意深く一貫して管理することが不可欠です。適切に管理され、優先順位が付けられたバックログが用意できれば、選択したアジャイル プロセスに従って、よく整備された機械のようにすべてが順調に進むようになります。
デジタルトランスフォーメーションはいつか完成するのでしょうか？いいえ、それは終わりのないゲームです。しかし、 Mendix 少なくとも競争力がつき、技術的負債とシャドー IT の存在を減らしながら、影響力のある管理可能な変更を迅速に実行できるようになります。ビジネス コラボレーションがすべて行われるため、財務部門の Sam と友達になれるかもしれません。