You frequently hear how technology benefits a company. But what does it really mean in terms of meeting ambitious timelines, reducing costs and boosting innovation through collaboration?
Recently, Schnitger Corporation, a market analysis firm specializing in engineering software, created a scenario of how a hypothetical company managed their transition to software as a service (SaaS) in order to bring their retail-oriented robot to market in under six months.
We wanted to expand upon that scenario and examine the challenges and triumphs this company would face had they operated without embracing digitalization versus implementing a SaaS strategy.
The fictional company, called Modern Robotics (MR), has built robots for nearly 30 years and has plans to revolutionize in-store retail. Amid reduced store margins, labor costs, employment shortages and theft, MR believes their robot is ideal for handling repetitive tasks, inventory management, stocking shelves and cleaning up.
Each robot, called the MRone, will use technology to move throughout the store and avoid people and objects. MR plans to meet their ambitious deadline by purchasing components and working with suppliers on integration. The company expects the MRone to send data to a cloud resource which uses a detailed store map to determine how the robot should perform which duties where.
Based on their current technology and operations, the challenge of creating the MRone seems daunting, if not impossible. How can investing in digital technology boost the Modern Robotics teams’ abilities to succeed? And what is the fate of the project if they continue as is?
MR anticipates launching its basic prototype in six months.
This blog series is going to look at two different versions of Modern Robotics as it relates to designing and manufacturing the MRone. One version observes what happens when they invest in new digital technology, the second version is if they keep their current set up in place.
But first, let’s take a look at their current technology.
MR’s current technology
Although MR has 30 years of experience in robotics design, the software they’re using, while capable, is a bit old-fashioned. This makes it difficult for designers to do their jobs. One barrier is that the design team can only access the software tools on expensive desktop machines. This means data is often stuck in silos, which limits the designers’ ability to innovate.
Over the years, the designers at MR have used many traditional desktop tools to design manufacturing robots. While those have been successful, the many shortcomings of this process are burdensome considering the tight timeline for the MRone.
From the lead designer’s perspective, there are several potential issues including how to discover downstream issues in production and translating design ideas into something that can be produced economically to spec. A significant roadblock with working with suppliers is the difficulty in importing or referencing parts and having to spend time re-modeling it.
With the responsibilities of managing hardware, lost data, software upgrades, viruses and other security threats, the IT team often seems overwhelmed as it supports a whole host of users. MR also uses additional software tools to operate its manufacturing plants, support sales, and manage service calls. None of the software is integrated.
Meanwhile, engineering uses many mechanical and electrical CAD packages; CAM from another supplier, various CAE tools, and lots of spreadsheets. Also, there isn’t a control system so data or workflow management is scattered with most documents shared via emails and cloud folder schemes. Fortunately, it’s all digital and not on paper.
The siloed nature of MR, common with most companies, means designers and engineers often work alone or with peers in their disciplines. These teams rarely come together for cross-discipline design reviews. A more collaborative culture is critical if MR wants to meet the aggressive timeline.
Of course, email is still used frequently to alert teams of new requirements, answer supplier questions, provide work assignments and pass data and information back-and-forth. Keeping track of everything is challenging and time is wasted looking for information. This translates to too much information with no certainty that you’re viewing the latest version.
Approaching the c-suite
With little time to make changes, the heads of the IT, design and engineering teams listed their wants regarding new digital transformation initiatives and approached the c-suite.
They wanted a modern, agile, and connected environment where their designers could use a cloud-based CAD solution allowing team members to work from anywhere, on any device so long as they had an internet connection. They also wanted automations to quickly and easily create drawings, lists and other documentation that meets the company’s standards.
Collaboration tools were key. They want colleagues to resolve open items and keep track of decisions within an open environment — everyone had to have the latest requirements, decisions and data available and not become reliant on the latest email thread or hope they received the most recent messages or changes. Poor communication had previously stymied other projects, some of which involved a misunderstanding about supplier parts availability which led to an expensive late-stage redesign.
Overall, the engineering, design and IT teams believed there had to be a single source of truth that every stakeholder was working from and where data was accessible.
The teams working on the MRone believed software-as-a-service was the best approach if they wanted to stay agile, flexible and ensure accessibility.
SaaS is hardly a new concept and something the c-suite was familiar with. So, when the they heard the arguments for investing in digital technology, which includes cloud-based SaaS, they considered the time-to-implement, how it would benefit or harm their proposed launch date and the cost.
How will their decisions impact the ability of their teams to meet the aggressive deadline?
We’ll separate MR in to two companies: MR-on-premises for the version of MR that does nothing and proceeds to create the new MRone like they have previously had; and MR-SaaS for the version that implements new digital technology like SaaS.
(There are several great on-premises solutions and the name isn’t a reflection of its benefits/drawbacks, but a way to distinguish to the two companies moving forward)
MR-on-premises will keep their setup as is. The c-suite argued that this has served them well in the past and there isn’t a need to make a perceived major overhaul when they are implementing a tight timeline for the MRone. It’s not that they were disagreeable to the idea, in fact, increasing their level of digitalization appealed to them. However, now was not the time, but they indicated they plan to revisit some of the ideas after the MRone prototype is created. They didn’t see any short-term benefit and didn’t think the culture of the company would accept the changing of digital transformation initiatives without some pushback. The c-suite for MR-SaaS were eager to learn more about Software-as-a-Service and how it could lead to a successful prototype launch. They initially worried about IP protection but trusted their IT manager was making the right call based on the reputation of the suggested SaaS provider. Integrating software and working off a single source of truth appealed most. They embraced the Shift Left approach to avoid costly mistakes in the last weeks leading to launch and saw the potential of releasing a better product with fewer bugs.
This concludes Part I. Stay tuned for the next blog which will cover how the two versions of Modern Robotics used their respective technology setup to meet the goal of launching their MRone prototype and what challenges they encountered along the way.
Want to learn more about Siemens’ SaaS offering? Check out Siemens Xcelerator as a Service.