Digital product factories enable a new business model at Toyota Financial Services

Vipin Gupta spent nearly eight years as CIO of Key Bank before joining Toyota Financial Services in 2018. While he leads all aspects of digital transformation and information technology, as CIO of TFS he is building a more digitally savvy workforce. Recently I spoke with Gupta about the transformation he has helped to lead, the strategy behind the new architecture, and how he has added digital skills to his team. What follows is an edited version of our interview.

Martha Heller: Can you describe Toyota Financial Services’ digital transformation? 

Vipin Gupta: The automotive industry has been reshaping into a mobility business, which goes beyond manufacturing and selling cars to providing services to move people and material safely from point A to point B. So, three years ago, we started asking the question, “If Toyota Financial Services were born today, how would we design it?” 

Our answer was to become a mobility-finance-as-a-service platform and grow from captive finance for Toyota and Lexus to providing financial services for other mobility companies. We wanted to offer the same quality services that we deliver to our own brands to other automakers and mobility businesses.

In April 2020, just seven months after we signed a partnership with Mazda, we launched our first private label business as Mazda Financial Services on a new multitenant mobility finance platform built from the ground up using modern technologies all in the cloud. 

How did you transform the business so quickly?

The key to our moving so quickly came from turning the transformation logic upside down. Yes, we need to transform the technology to transform our business, but before that, we focused on transforming our behaviors to move more quickly with new digital business practices. Our early focus on behaviors and habits first was the real game changer. 

One key to driving change in behaviors was shifting our operating model from projects to digital product factories.  We knew that the traditional time-bound project model was inefficient, with administrative overheads.  Product Digital Factories, on the other hand, have a dedicated team, or “factory,” accountable for continuously improving a product capability.

Second, we adopted the mindset of building a software product just like we build cars. We applied Toyota’s world class car manufacturing and engineering practices to software engineering. We designed each digital factory with a fixed capacity that delivers software changes on a fixed cadence of every two weeks. By fixing the capacity and output cadence each factory teams were naturally forced to prioritize to deliver what matters most for when it is needed, inspired by just-in-time principle. This helped deliver the highest business value capabilities early, and at lower cost of delivery.

Third, we pulled the company’s top decisionmakers into leadership action teams, which meet regularly, like a scrum, and answer only one question: What is the impediment to a factory’s deliverables? The goal of the leadership action team is to remove that impediment with a belief that when impediments are removed, the empowered factory owners will lead their teams to their goals quickly. This has given us amazing speed.

A significant source of waste in IT comes from the time-to-decision-making inside and outside of IT. The speed of the leader is the speed of the team. The decision-making waste starts at the top of the organization. Once we have clarity of decision at the top, the teams deliver quickly.  

How did you approach the new architecture?

Our first guiding principle was that instead of modernizing existing legacy systems one by one, we would design a completely new architecture all in the cloud, as if we were born today, which freed us from conversations about upgrading systems. 

Second was that our architecture for every system would be a multitenant design tied by a common tenant I.D. across all systems. This would allow us to provide services to customers through a shared infrastructure, while keeping the data separate. That balancing act—sharing infrastructure but not data—means that every system that we introduce to the new ecosystem is designed to be multitenant, which influenced our data models and the design of data supply chain.

The third principle was not just “API first” but “API must” for every system to interact with each other, and for external partners to use our services. APIs were not an option, choice, or decision point. API and microservices must be a way of life.

Fourth was designing for agile analytics, where the data, regardless of where it resides, will be available to our analytics and data-science teams. We call this a data supply chain, where rather than building a system data interface to push data into the data warehouse, we created an integrated data cloud to continually pull data from our systems. We not only streamlined data flow for analytics, but we also reduced point-to-point system interfaces and liberated our operational systems from the accountability to push the data.  

Finally, for customer experience, we went one step beyond omnichannel to “on my channel,” which prioritizes the customer point of view in how we design experiences.

Those elements—all in the cloud, multitenant systems, “API must,” pull-based data supply chain, and “on my channel” experiences—became the guiding principles for every system that we built or bought. This standardized approach allowed us to move quickly in building the new architecture.

What advice do you have for other CIOs in designing a new architecture?

One piece of advice is not to be so focused on the functional requirements of the architecture that you ignore the technology operational elements, like monitoring, detection, and self-healing capabilities. Had I to do it again, we would have thought more about the operational elements of the ecosystem and designed them proactively rather than reactively, as we are doing now.

Also, a new digital architecture and operating model requires teams to grow new skills. In addition to acquiring talent from the outside in this tight talent market, we focused on developing our existing teams. So, we created the TFS Digital Academy around the idea of “learn, do, teach, do” so that we can all grow our digital competencies together. Our thinking is that teaching is key to learning, and there are no better teachers than our own experts. Whether you are a TFS employee or a consultant, you are getting trained on the same practices. In addition to sharpening our skills, this drove consistency in our behaviors and practices, further reducing waste and increasing speed.

Based on the role you are playing at TFS, how do you see the CIO role evolving?

The role of the CIO going forward is to be the architect of the future version of the business. The CIOs have a holistic enterprise vantage point to influence the design of not only the platform, but also the organizational model, business model, and process models. Good CIOs transform IT from inside, but great CIOs use design thinking and inclusivity to transform IT by changing what happens outside of IT.