August 15, 2022
Over ten years ago, we put accounting and other related systems in the cloud. Back then, only few high-tech engineers began to use the word “cloud”, so the general level of understanding within the company was very low. I spent a lot of time in my office talking to engineers from the server company, or even their director in order to build a system that allowed us to access accounting systems, financial statements, and other required documents from anywhere in the world. That may sound like a completely ordinary cloud system today, but at the time, there were almost no other companies building systems like that. When we demonstrated it in Japan, the participants were amazed, and we saw an increase in our business management contracts.
From about five years ago, however, the number of cloud-native systems began to expand, and it became more common for these systems to allow access from anywhere in the world via the cloud. I could see that our structural advantage would collapse, and I spent sleepless nights wondering how to steer the company forward. How should work be arranged? How should we do our jobs in the future? I don’t know how many dozens of times I came up with a vision of that and then erased it again to start over. Then, about four years ago, I made the decision that we would develop our own proprietary software. We had tried all kinds of general use packages, no-coding solutions, etc., but they were all lacking in some way, and we had seen that none of them actually worked in the way that we were expecting. At the time, all we knew for sure was that it was theoretically possible to create the software we envisioned. Even so, I felt that our only choice was to move forward with development on our own. But when I proposed that we migrate the work of one of our company’s departments from Excel to the system that we were to develop, I experienced extreme resistance. “Do we have the development experience?”, “Do we have the funding?”, “What assurance do we have that it will actually work?”, “It’s too risky!”, “What will we do if there are big problems with it?” etc…; there were any number of reasons for this pushback. Under such circumstances, however, there was one staff who decided to support the project and help me create the prototype. The two of us worked together, sometimes late into the night, to build the program. We would reach out to professional programmers when necessary and eventually finished the prototype.
Finally we were finished, I thought. But it immediately turned out that it wasn’t completed yet. Although it worked for basic operations, it would produce incorrect results when the conditions were changed even slightly. A huge amount of testing was needed to find and eliminate those bugs. I started looking for help, and two staff members agreed to provide support. Neither of them knew anything about development, but they were able to input the test data and determine whether or not it was coming out properly. I moved out of my office and sat at a small desk in our meeting space while the two of them sat at a conference table behind me, and we got down to work. Despite not speaking Japanese, they taught our newly arrived intern from Japan the confirmation procedure as well as how to help write the manual. With this new system, we somehow managed to make it through the first fiscal year of our efforts. I thought I had answered my critics, but what with all the time that we spent, including my own, the development staff, and the support staff, as well as payments to our outside system engineers, we suffered a big loss for the year. It wasn’t a result that I could take pride in.
One of our employees who had strongly opposed the project quit, and then another, saying, “Mr. Takano is ruining the company with his reckless ways.” Nevertheless, I believed that the company’s future depended on our own efforts to create the environment in which we wanted to work, and I continued on with development. We officially hired an engineer, as well as recruiting new staff who had IT consulting backgrounds, and we established a contract with an excellent external engineering firm that understood what I was trying to accomplish.
Fast forward four years since we started development and three since the staff revolt. Operational errors were reduced by 80%, the time we spent on our work overall was now under half of what it had been, and a department that was previously in the red had now grown to the point where it was making profit on its own. In addition, as a result of developing our own system for internal management and control, we can now instantly generate a profitability chart for every project that we are working on.
It takes a determination to do something that has never been done before. In order to project our work in the future, I envision how we want to be working ten years from now, and reverse engineer from that standpoint. Since it’s not a world that we can see with our eyes, it’s not something that I can prove. However, it is all too easy to become completely caught up in the busyness of our everyday work, and if we don’t clearly envision how we want to be in the future, we will lose sight of the road that we ought to be taking. There is he who points out the way forward, who overcomes every obstacle along that path, who accomplishes the objective. Even if no or very few give appreciation for his efforts and courage, he will not give up until he comes out with the result he desired. That person is called an innovator. Only with a combination of belief, courage, passion, and execution can an unproven project be successful.
The more innovative a project is, the more difficult it is to gain an understanding by the surrounding people; courage and passion are required in order to make a start. We cannot be bound by the past if we are to survive in a fast-changing world. We must have the courage to move forward with an eye to the future, as well as the passion to overcome the obstacles in our way. The more innovative a project is, the more likely it is to fail. But our company is not afraid of failure. In the event that we do fail, we don’t make fun of the people who suffered the failure. That’s because we believe that those who have the courage and the passion to attempt new things will surely be able to learn from their mistakes. And we recognize those who support innovators as highly as the innovators themselves. How encouraged I felt by those two staff members who sat with me in the meeting space and helped with the testing when I was struggling with our new project. Not everyone can come up with brand-new innovation, but anyone can indeed be a supporter. Don’t be a free rider tagging along behind the ones who continuously try, but do what you can to support them. If every member of our company is unified in this attitude, we will surely grow as an organization, and every individual who offers their support will also undoubtedly grow as well. That is why we will keep trying, sometimes accepting failure. Those of us who cannot be the innovators who struggle forward can be supporters instead of free riders. That is the kind of organization that I want us to be.
コメント