“The Moment Our Thoughts Changed”
The Reason We Decided on In-House System Development
The Reason We Decided on In-House System Development
Yoho Co., Ltd.
System Management Tower (Information System Unit)
Mister Sou Kimura (Picture left), Mister Takuro Kishi (Picture right)
Overview of the Project
(Mr. Kimura) The main project we undertook was the supply and production management (SP management) system.
We are a company that manufactures craft beer. We produce and distribute our products to stores, and it takes around 1 or 2 months after production for the beer to actually reach the stores where consumers can buy them. Due to this lead time, we cannot respond to requests such as “please prepare more beer immediately because it sold well” unless we have stockpiles. On the other hand, since beer is perishable, if we produce a large amount, there may be excess stock that we have to throw away.
Striking a balance between having stockpiles for sudden demand increases (such as when our beer is featured on media), and not having excess stockpiles, was the big objective for SP management at our company. Our company has an expert team that does analysis to achieve a high level of SP management.
This was how we had managed our inventory in the past. However, due to recent increases in shipping volumes, our ability to ship products from our one and only warehouse would have been maxed out in a few years, so we had been debating the creation of more warehouses. However, exporting from multiple warehouses would seriously complicate the management of inventory, and many problems surfaced. There was a limitation to humans doing the management, and with comments from on-site workers, we decided that the information systems department and on-site workers should cooperate to solve the problem using the power of IT.
GCP Integration Background
(Mr. Kimura) Since last Fall, after the creation of a Business Requirements Document, we started looking for a partner company that would improve our system, and inquired with a few businesses. Due to SP management often consisting of business-specific rules and knowhow, there wasn’t an accessible system package we could find. Although we spoke with many IT vendors, all of them recommended building a system from scratch. In the end, if we were to outsource the development of our desired system to an IT vendor, the development costs were not acceptable for us.
(Mr. Kishi) The system we had been using was made with Google Spreadsheets. However, since this spreadsheet made heavy use of importrange functions and automated many calculations across tasks, it was an extremely complicated system. This was compounded by the fact that the employee who developed the system had left the company, so the system had become a black box.
(Mr. Kimura) Considering that a non-IT knowledgeable company like ours was able to create the required tool on Google Workspace (ex G Suite™), we determined that if we could develop a way on our own to continue the use of Google Spreadsheets as the UI with modifications enabling the database to be uploaded to Google Cloud, we could maximize the speed and flexibility due to our understanding of the operation, all the while minimizing cost. When we inquired with Cloud Ace to see what their work would be like, we were told that “it could probably be done quite easily”, so we decided to start with them. However, we were worried if we could maintain the developed system on our own. We spoke with them about this worry, and were told that the system for this project could be created without any complicated architecture, and also that “Yoho Brewing is probably the most familiar with the operation”. This led us to believe that instead of outsourcing everything from development to maintenance, by developing the system to be easy to maintain and modify on our own, we could gain a competitive advantage in the marketplace. We wanted Cloud Ace to support us accomplish that. We had already determined some quite specific requirements, and already had an idea of how we wanted to use the final product, as well as what we wanted to create. However, since our company barely had any employees with experience developing using Google Cloud, we didn’t know how to achieve our goals. By talking with Cloud Ace, they provided us with suggestions on methods to achieve our objectives, and our goals gradually solidified.
How the System is Structured
The main point of our system is that it is a combination of BigQuery and Google Workspace (ex G Suite™) Spreadsheets.
In the old system, the spreadsheets served as both the database and screen UI, had many combinations of functions, and referenced between spreadsheets. Due to these factors, analyzing data that jumped between spreadsheets was made difficult, and a single breakdown of a function risked collapsing the entire system. Therefore, we decided to revise the old system, transfer the database to BigQuery, and only display the inputs that users actually interacted with on the spreadsheet UI. We feel that splitting the user’s inputs and the data has increased maintainability and expandability. Furthermore, by pulling all of the data that was spread across multiple spreadsheets into BigQuery, we feel that this system development was an investment into our future data operability. We would like to pull other pieces of data within the company into BigQuery in the future.
Effects and Takeaways
(Mr. Kimura) Since we know best of what we want, I believe the biggest effect this has had was the realization of the importance of trying to make our own systems. We had already decided on developing our own solutions, as much as possible, for the digitization of our company’s strongest core businesses, and the confirmation that this was possible was very important. In today’s world, there are many SaaS cloud services, as well as low or non-coding platforms, and I believe this has made development very easy for user businesses.
That being said, an in-house solution isn’t perfect. Therefore, instead of trying to accomplish everything in-house, I believe that prototyping in-house to confirm what should be made, and then getting help from IT vendors when the task becomes too complicated will still be necessary. Still, the user business being able to hold the initiative is a huge change.
(Mr. Kishi) By incorporating on-site employees into the development process, we were able to build a system that matched actual operational application. Since we weren’t confident that we could build a system that had considered minute details, such as the methods of operation, the help we got from Cloud Ace in that aspect was very important.
While a non-specialist of IT developing the system carries the risk of failure, I think that being able to build what we want is still very important.Since the development made each one of our core jobs clear, the project also was a catalyst for us to start thinking which parts should be built with special care, which parts should be simplified, and which parts should be automated altogether.
(Mr. Kimura) To be honest, at the beginning, I thought there was a 50% risk of failure.However, through our development members’ commitment and Cloud Ace’s considerate support for them, I feel that once our team began forming, we were able to stand at a starting point and say “this might work!”.
Since a big problem with the last system was the over-reliance on the employee who developed it for modifications, to prevent that scenario from happening again, we will put effort into continually training resources for system upgrade and operation.
Since we have realized that we can develop easy-to-use systems on our own using Google Cloud, we would like to increase our company’s competitiveness by actively incorporating SI 2.0 and digitizing our business for fields not limited to the SP management system.