Wait… a system isn’t finished just because you’ve completed the system itself?
Some time ago, I was involved in a project to implement a financial system from London.
At the time, my first question was, “How can we make this core financial system work in Japan?”
Since it was a system being introduced from overseas, naturally, some adjustments were necessary to accommodate Japanese business processes.
But the basic approach was simple.
Configure the core system as much as possible.
Only develop the parts that could not be handled through configuration.
And rather than developing everything in Japan, we would basically ask the London team to handle the required development. From there, the development would be carried out at the appropriate location.
“I think we can make this work.”
I remember thinking that.
But then came the next challenge: the surrounding systems.
When the Core System Changes, Everything Around It Changes
Once the new financial system was introduced, the systems connected to it also had to change.
Data fields changed.
Interfaces changed.
Data formats changed.
The receiving systems had to be modified accordingly.
We checked each system one by one and connected them one by one.
Gradually, we began to see the overall picture of the internal systems.
“Okay. We’re finally starting to see a path forward internally.”
Just when I thought we were getting there, another challenge appeared.
This time, it was another company’s system.
Financial Systems Cannot Be Completed Within One Company
In the financial world, it is impossible for one company’s system to handle an entire business process by itself.
An order comes in.
It is checked.
It is approved.
Payment is made.
The transaction is recorded.
And then the information is shared with other systems and companies.
In other words, many companies and many systems have to work together to complete a single transaction.
That is where one question becomes critical:
How do we connect them?
Which proxy should we use?
What data format should we use?
How frequently should the data be sent?
Should our system connect to theirs?
Or should they connect to ours?
And, of course, does the connection involve any additional fees?
All of these things have to be decided and communicated to the other company.
And communicating the requirements is not the end of the process.
Questions inevitably follow.
“What does this data field mean?”
“Can your system support this format?”
“How should we handle the test environment?”
One question after another.
While responding to those questions, we also had to plan the connection tests.
Connect Systems One by One. That Is How Business Is Built.
Looking back, I realized that one of the hardest parts of a system implementation was not simply building the system itself.
It was connecting the systems one by one.
And more importantly, reaching agreement between people and companies about the conditions for those connections.
Only after that process is completed can the actual business begin to operate.
This was not unique to the financial system we introduced from London.
The same thing applies to systems developed in Japan.
Very few businesses can operate entirely within their own systems.
Customers, business partners, financial institutions, logistics companies, cloud services, external APIs…
As digital transformation progresses, systems across companies will become even more deeply connected.
That is why DX professionals need more than just the ability to build a good system.
They need the ability to design how systems should connect so that the business can actually move.
System integration is not simply an IT task.
One connection.
One piece of data.
One agreement.
The accumulation of these small decisions connects companies and ultimately creates new business.
I can do it! Let’s take the first step tomorrow.
コメント
コメントを投稿