主な要点
- Enexis は、ローコード開発を使用してフィールドエンジニアのプロセスを最適化し、オランダの変化するエネルギー環境に対処しています。
- 社内外の24人を教育 Mendix 開発者は、ローコードと アジャイル開発サイクル。
- オランダ国内の2.8万世帯以上に電力を供給し続けました。
「変化は難しい」と同僚は、新しい経費システムにアクセスしようとしながら嘆きます。新しいシステムや仕事のやり方を変えると、どんなに小さなことでも困難が生じ、プロセスや人々が混乱します。
私の同僚のように（ちなみに彼女は新しいシステムを堂々と理解しました）、仕事のやり方を変えることはどんなビジネスにとっても難しいことです。しかし、変化を考えてみましょう エネクシスオランダのエネルギーの 3 分の 1 を管理する電力網メンテナンス会社である は、エネルギー市場の変化に対応するのに役立つアプリケーション開発プロセスを変更しました。同社がサービスを提供する何百万もの家庭や企業の生活が危機に瀕していました。
ここでは、Enexis がアプリケーション開発と配信方法に大幅な変更を加え、企業と顧客に重要な製品を提供する方法を説明します。
変化の指揮者
オランダのエネルギー事業はかつては非常に安定しており、予測可能だった。 オスカー・バーガーEnexis の CIO オフィス マネージャーである氏は、「かつては非常に安定した予測可能なビジネスに携わっていました。電気やガスなどのエネルギー需要は一方通行で、都市開発と経済成長に基づいています。何年も先の計画を立てることができました。」と述べています。
しかし、バーガー氏の言葉を借りれば、この国は最近、エネルギー転換の真っ只中にある。電力需要が高まっているのだ。バーガー氏は、電気自動車の売り上げが伸び、電気自動車の購入によって家庭の電気代が倍増したことを例に挙げている。これは、新しい消費者のニーズに対応するために、家庭や企業の設備を変更することを意味している。
消費者も、ソーラーパネルなどの技術によって電気の生産者になりつつあります。そのため、かつては一方通行だった電気の流れが双方向になりました。
最後に、二酸化炭素濃度の上昇を受けて、オランダは2年までにガス生産を停止することを決定しました。「つまり、ガスのインフラは2050年頃には時代遅れになるということです」とベルガー氏は言います。「問題は、それをどうするかということです。」
一方向のエネルギーフローから双方向のエネルギーフローへの変更、そして最終的にはガスからの移行により、Enexis はインフラストラクチャの保守方法を変更する必要がありました。
上記のすべての変更を実現するには、Enexis の現場エンジニアと下請け業者がより効率的に作業できるように IT 部門の支援が必要でした。
ローコードトランスフォーマー
EnexisのITチームは、その答えはアプリケーションポートフォリオの管理方法にあると気づきました。大規模なコアアプリケーションを持つ大企業として、ミッションクリティカルなシステムを管理すると同時に、ビジネス部門の新たなニーズに迅速に対応し、2.8万世帯に電力を供給し続ける必要がありました。そこで、Enexisは Mendix ローコード開発プラットフォーム.
ガスのインフラは2050年頃には時代遅れになるでしょう。問題は、それをどうするかということです。
エネクシスは「移行型アーキテクチャ」を構築し、 Mendix彼らはITインフラ全体を置き換えるのを待ちきれませんでした。 革新し、ビジネスと顧客のニーズを満たすそれはすぐに実行されなければなりませんでした。移行アーキテクチャにより、開発チームは標準では達成できない速度でアプリを設計、開発、展開できるようになりました。 エンタープライズアーキテクチャバーガー氏は、暫定的なアーキテクチャを自分のオフィスで正式に承認することの重要性を認識しており、チームに「定義されたアーキテクチャに従わない言い訳」を与えてしまったと冗談を言った。
しかし、結果は冗談ではありませんでした。ステッカー アプリケーションを例に挙げてみましょう。Berger 氏によると、前提はシンプルです。Enexis ステーション 40,000 か所すべてに、安全意識を高め、その場所に設置されている特定の機器によってもたらされる特定のリスクに対する注意を促すステッカーを貼る必要があります。これらのステッカーを置き換えるプロジェクトを定義して実行するには、かなりの作業が必要です。
ステッカー アプリケーションにより、Enexis はオンデマンド方式でステッカーを更新できるようになりました。ステーション内のセンサーが、ステーションに新しい安全促進ステッカーが必要であることを近くの現場エンジニアに伝えます。エンジニアは最も近いステーションに行き、ステッカーを交換し、それをアプリケーションに直接登録できます。位置情報サービスを使用して、すでにステーションの近くにいるエンジニアに警告することで、エンジニアの邪魔にならないように追加の小さなタスクを割り当てることで、時間とリソースを節約できました。
アプリ配信の急増
デジタルイノベーションはステッカーアプリケーションの成功で止まりませんでした。むしろ、Enexisは人材チームの構築方法を再評価し続けました。Enexisはアプリケーションファクトリーと名付けたものを開始しました。それは4人の Mendix 開発者たちは移行期のアーキテクチャに取り組み、最適な使用方法を学んだ。 Mendix 3か月後、そのチームは2人ずつの2つのチームに分かれ、各チームにさらに2人の開発者が加わり、 Mendix24か月後、チームは再び分割され、より多くの開発者が配置されました。現在までに、社内および社外のXNUMX人の Mendix 開発者は、ローコード以前の Enexis では想像もできなかったスピードでアプリケーションを構築できます。
結果: 100 年間で XNUMX 個のアプリケーションが構築され、展開されました。
ここで重要なのは、これらの専任のアプリケーション ファクトリー チームの人数だけでなく、そのチーム内の役割です。UX に関する標準を作成することは非常に重要です。スクラム マスターは生産ラインを動かし続けます。チームの規模は、構築するアプリケーションの規模に応じて拡大または縮小します。アプリケーションが小さい場合 (依存関係が少ないなど)、開発者は 1 人で十分です。アプリケーションが大きい場合は、開発者が 6 人必要になることもあります。
より多くの人材でより多くのローコード アプリを作成することで、Enexis は価値実現までの時間を短縮できました。 たとえば、Berger 氏はチームがわずか 3 か月で構築した検査アプリケーションを挙げています。このアプリケーションを使用すると、現場のエンジニアが駅に行って塗装が必要であることがわかったら、アプリケーションを開いてその旨を伝えるだけです。開発チームが構築した SAP 統合により作業指示書が作成され、その作業を引き受けることができる Enexis の下請け業者に送信されます。XNUMX か月以内にアプリケーションが構築され、駅の維持管理の計画にかかる時間が節約されました。
100 個のアプリケーションは大変なことのように思えるかもしれません。アジャイル手法を採用し、製品所有者に実際に決定を下す権限を与えることが、この規模を実現するための重要な要素でした。製品所有者は、開発者が各スプリントのプロジェクトを評価し、優先順位を付けるのを支援します。この明確な優先順位付けにより、Berger の部門は大規模なアプリケーション ポートフォリオを強化し、維持することができます。
Enexis の App Factory は、工場のラインで単調に働く労働者のように聞こえるかもしれませんが、Berger 氏はその比喩の解釈に対して警告しています。これらの開発者は工場労働者ではありません。まったく違います。チームは自律的で、どのアプリケーションを構築または更新するかを自分で決定します。Berger 氏によると、「比喩の強みは、組織化されていることです。そして、私はアジャイルが組織化されていることを好みます... 工場のように機能することを知ることは重要だと思います。」
あなたは本当にどれくらい先まで見通すことができますか？
Berger 氏は、Enexis は約 2 年先を見据えようとしていると述べています。しかし、IoT のように常に新しい課題が生まれます。同氏は、同社の App Factory が開発し、ステーションに IoT センサーを設置するのに役立ったスマート アプリケーションの別の例を挙げています。フィールド エンジニアがこれらの IoT センサーが配置されているボックスを設置すると、信号が中央ステーションに送信されます。Enexis はボックスが設置されている場所からこの信号を受信でき、フィールド エンジニアはアプリケーションで確認通知を受け取ります。
Enexisはわずか100年でXNUMXのアプリケーションを開発し、前例のないローコード開発会社を立ち上げました。 アプリケーション開発プロセス 大規模な提供により、顧客のニーズの変化に対応し、エネルギー市場の変化に対処し、常に将来を見据えることができます。
