The Current State and Future of the IT Vendor Industry
In recent years, the digitalization of the economy and society has advanced, and the IT industry’s market has continued to grow along with it. Recently, new technologies have appeared one after another, such as the cloud, managed over the internet; big data, which analyzes large volumes of data to identify trends; AI (artificial intelligence); and 5G. Moreover, the need for corporate DX is now common knowledge. There is no doubt that the IT market will continue to grow without slowing down.
The trend toward digitalization across society is expected to continue, and further advances in IT technology and services will be in demand.
A variety of companies support this IT industry. One type is the IT vendor (also called an SIer), which designs and builds the systems that underpin the IT industry. There are also cloud service companies and software package companies that develop IT systems themselves as packages.
In this column, I will explain the current state of these IT service companies and the direction in which they are likely to head.
The Current State and Future of IT Vendors
Once companies reach a certain size, they begin introducing IT systems in pursuit of efficiency. Starting with small-scale accounting systems, the scale gradually expands to systems with diverse purposes, such as sales management and customer management.
In recent years, software itself has evolved remarkably. There are packaged software products and inexpensive options that use cloud systems. There is also a method called “scratch” development, in which a system is built from the ground up to fit a company’s business structure and needs precisely.
It is IT vendors that build these “scratch” systems.
The scope of IT vendors’ work can be classified as follows.
(1) System development
(2) Telecommunications infrastructure
(3) Web
(4) Machinery
(5) Consulting, etc.
However, a considerable proportion of these IT system implementations end in failure.
IT orders range from several million yen to tens of millions or even hundreds of millions of yen, so the costs are by no means trivial.
Costs are generally calculated from “man-hours,” that is, the processes required for system production and the number of people and days involved, but this depends on what the IT vendor claims. Moreover, depending on the development, it can take anywhere from six months to several years, consuming both time and money.
Yet quite a few systems turn out to be unusable once completed, and all that effort simply “goes down the drain.” In some cases this has even led to lawsuits, and it can have a serious negative impact on corporate management.
So why do IT solution implementations fail like this?
The reasons are that the ordering company does not know how to work with IT vendors, and the IT vendor receiving the order cannot understand the company’s needs. Because of these two factors, IT implementations often fail.
Let me start by explaining the problems on the company side.
It is a different story if there are employees with knowledge and experience in implementing IT solutions in-house, but most companies, especially SMEs, have no experience implementing IT solutions, so they struggle first of all with selecting an IT vendor to place the order with.
Since it is case by case, it is difficult to judge what is good or bad, but let me explain some general points of caution based on cases I have experienced.
Let me introduce a case of a failed implementation at one company.
While consulting for this company, I attended a presentation by a major IT vendor together with the client company to hear their explanation regarding the introduction of a core business system.
About ten people came from the IT vendor, and the presentation began with their track record and high industry market share. As the explanation went on, the client’s president and others showed interest, and the atmosphere shifted toward choosing this IT vendor.
However, I alone intended to oppose introducing this company’s system. That was because, based on my experience, several reasons for opposing it had emerged.
Major IT vendors usually have a very effective business model. Completing a commission from one company to create an expensive IT solution program becomes one item on their track record. But it does not end there. They copy the completed system, adapt it for general sale, and resell it as packaged software.
A full lineup of general-purpose packaged software is assembled, ranging from products costing several hundred thousand yen to those costing hundreds of millions of yen. From the next project on, they simply use this packaged software and customize it to fit the client’s needs. Customization generates further fees. In this way, the mechanism generates sales through steps that are almost like alchemy.
I am not, however, raising issues with this business model itself. The problem arises afterward.
IT vendors that have grown rapidly and built an excellent track record are always struggling with a shortage of skilled system engineers and sales staff who are well versed in IT solutions. Under such circumstances, for a from-scratch project involving large sums of money, the IT vendor assigns excellent personnel, but if the job looks like it will only involve customizing packaged software, they decide it is fine to assign less experienced staff.
As mentioned earlier, companies are also not good at giving clear orders on exactly what they want modified in the packaged software. Discussions therefore tend to end up between people on both sides who lack knowledge and experience.
To protect themselves from such vague orders, IT vendors create a document called a “requirements definition.” This document draws out and summarizes the changes from the company’s order. While this is a natural process from a business standpoint, the requirements definition has a hidden purpose: protecting the IT vendor as a kind of contract.
Companies make various requests about the kind of program they want, but because they lack specialized knowledge, their requests tend to be vague. The IT vendor compiles these into the requirements definition as the company’s order and builds exactly what it was told. When the finished program is actually used, complaints inevitably arise, such as “it’s hard to use” or “it lacks functions.”
This is where the requirements definition created at the outset shows its power. The IT vendor asserts that “we built it exactly as stated in the requirements definition.” Any problems or complaints that arise afterward become “separate projects” not covered by the requirements definition. The company is left with no choice but to put up with a hard-to-use program or place an additional order as a new project. An additional order becomes a new order, incurring substantial costs. In this way, the requirements definition serves as the IT vendor’s insurance. This is the reality of IT solution implementation.
The reason I opposed the IT vendor mentioned above was that so many people from the vendor came to the presentation. When many people come, companies tend to think “they are really committed to us,” but in fact the roles are simply divided, and there is a high probability that no one is in charge of pulling everything together. If there were such a person, that person could do all the talking, and there would be no need to bring ten people along.
In addition, talking about market share and track record first is a sign of a lack of confidence in the substance, and in fact the content of the presentation gave exactly that impression. That is why I opposed it.
However, the company did not heed my advice and decided to go with the IT vendor. Perhaps because I had voiced my opposition, they stopped listening to my other advice as well, so I ended my engagement with the company.
Afterward, just as I had predicted, the IT vendor’s software was never put into use, and I heard that around 200 million yen had gone down the drain. The company’s performance also declined thereafter.
To avoid failure with IT solutions, it is desirable to engage a consultant who understands the company’s needs and challenges, as well as the characteristics and programs of IT vendors, and can skillfully bridge the two; however, excellent consultants are not easy to find. There are growing calls to reduce costs through IT, but that is only possible if you can make full use of IT. The choices you make here and how well you implement IT are what determine success or failure.
The Current State and Future of Packaged Software and Cloud Service Companies
There are companies that sell packaged software.
As noted earlier, building from “scratch” is expensive and carries a high risk of failure.
“Scratch” systems are built to suit each company’s unique circumstances, whereas packaged software is built for common corporate challenges and needs. Because its functions are standardized and it is mass-produced (replicated), it is priced lower than “scratch” development.
That said, while accounting software may be one thing, packages at the level of core business systems can cost hundreds of millions of yen to implement.
Packaged software can usually be “customized” to fit specific needs. However, customization is charged separately, and it is outrageously expensive. One often hears stories of companies that thought they had bought packaged software cheaply, only for it to end up unbelievably expensive after customization.
This is a case from when I previously served as an executive at an advertising company. For the first two years after the company was founded, we had our tax accountant handle data entry into the accounting software. Later, as the company’s sales grew to several hundred million yen, we hired accounting staff in-house and set about selecting accounting software.
The company that came to pitch to us was a major listed accounting software firm. Although I was involved in management at the time, I was an outsider when it came to accounting software. The decision on introducing the software was therefore left to the president.
The salesperson’s persuasive presentation paid off, and we decided to purchase this company’s accounting software package. As I recall, the purchase price was 4 million yen and the running fee was several tens of thousands of yen per month. Adding the hiring of accounting staff, this meant a total cost increase of 300,000 yen per month. Ordinarily, this should have solved everything.
However, it later became clear that this accounting software was not suited to our business. The software was also quite sophisticated and difficult to use, and I began to see the accounting department in disarray. In the end, it took nearly two years before the accounting software functioned reasonably well.
Belatedly realizing this was a problem, I consulted a system company I knew, and they told me that the software was not suited to a company of our size and that there was simpler accounting software available. When we purchased the recommended accounting software and tried it out, all the problems we had been having were solved in no time.
In the end, we boldly scrapped the original accounting software and terminated the running contract with that company. This was a misjudgment by the president and us executives, and I feel sorry for the accounting department.
Since this incident, I have been careful about sales pitches from outside companies.
Thus, while the hurdles to implementation are lower than with “scratch” development, packaged software also carries its own risks.
Perhaps as a way to overcome this,
cloud services for businesses have spread rapidly in recent years.
You have probably been seeing more and more advertisements for cloud software such as attendance management, MA tools and HR management on TV, in taxis and elsewhere.
“Cloud” literally means a cloud in the sky; these services are managed centrally on servers located in strictly controlled system centers somewhere outside the company, and are used by running software within the cloud. The locations are never disclosed.
Because all software is used via the internet, it can easily be used not only inside the company but also from outside on laptops, tablets, smartphones and the like. The cost performance is high, but like packaged software, it is not built for your company, so it is not necessarily easy to use.
In particular, companies that cannot afford to spend much often introduce these cloud services,
and since cloud services each cover only individual functions, they need to introduce several of them.
This then gives rise to the following challenges.
(1) They do not know what guidelines to follow in deciding which cloud services to introduce.
(2) Multiple cloud services end up disconnected from one another, making operations cumbersome.
(3) Is there no way to connect these cloud services together?
Let me give an example. This happened fairly recently. A company we began supporting in formulating its corporate strategy was using a certain firm’s cloud-based customer management (CRM: customer relationship management) software.
It was a type charged according to the number of users, at 10,000 yen per user. They had signed up for 40 users, so it came to 400,000 yen per month, or about 5 million yen per year. The reason they introduced this software was the same as in my own experience: they signed the contract because they were convinced by the presentation and sales pitch.
However, CRM requires a certain degree of know-how, and it was premature for this company’s employees to handle it with their skill level. CRM is only a tool, and it has no value unless you can make full use of it. Apparently they had been told that introducing it would dramatically boost sales, but when they actually tried it, it was not easy to use.
I promptly proposed that the company cancel the customer management software, coached them on a customer management method using simple email software, and as a result we also succeeded in reducing costs.
As this shows, even cloud services have disadvantages.
There are many companies that, after introducing cloud services,
end up with “treasures they never use,”
incurring costs without being able to use them effectively.
There are many such companies.
Why a Third Type of System Company Is Needed
As described above, IT vendors going forward
will be unable to expect future growth
unless they eliminate implementation risks and dispel their high-cost image.
Markets such as telecommunications infrastructure, web, machinery and consulting will likely not disappear,
but core business systems are rapidly migrating to cloud services.
There may even be concerns that IT vendors centered on core systems will face the risk of extinction in the future.
Similarly, packaged software companies will find themselves in an awkward position due to high costs and other factors.
Cloud services are expected to continue growing,
but the challenges from the company’s perspective are as described earlier.
Here, a large air pocket comes to light.
98.2% of Japanese companies are SMEs.
Only large companies can afford “scratch” systems,
and that demand is also declining.
As a result, consideration of using “cloud services” becomes more active, mainly among SMEs.
However, for cloud service companies,
all that matters is selling their own services,
and proposing combinations with other companies’ services
is neither part of their job nor something they have knowledge of.
Likewise, IT vendors want to propose “scratch” development, which allows them to book large sales,
and they have no incentive whatsoever to go out of their way to propose another company’s inexpensive “cloud services.”
As a result, companies that need to introduce IT systems have no choice but to have their corporate planning, general affairs or systems departments
design the implementation on their own.
Naturally, because they lack specialized knowledge, they fail at implementation, even with “cloud services.”
In this way, there are no IT system companies that provide support from the company’s perspective.
Therefore, our company
is rapidly developing solution services
to solve this problem.
What is required for this service is:
(1) The ability to design IT systems tailored to corporate needs.
(2) Selecting cloud tools, combining them and, where necessary, programming them.
Examples:
Our solution services division is now very active, building systems for many companies.
However, we do not intend to provide this service on our own;
if more IT system companies of this new type emerge,
I believe it will be good for society.
* This column is excerpted from “The World’s Easiest Course in Corporate Strategy Planning.”
Text: Hiroshi Ashida
● Column articles are scheduled for publication on the 1st of each month.
Column scheduled for November: “Why We Make Films”