The introduction of cloud (specifically SaaS) has had a profound impact on the methodology that organizations use to roll out software. The speed and scale that SaaS moves across a company is unprecedented and so much so that its difficult to even compare to previous non-SaaS projects. So the question is, how can manufacturing operations also take advantage of this software paradigm shift without introducing risk to the stable operation of their sites?
Cloud has some obvious advantages when compared to traditional software, most notably it provides these value drivers which are all built into the SaaS pricing as part of the software design paradigm:
- Experts that maintain and manage the hardware, disaster recovery, and networking infrastructure
- Software updates and maintenance of the platform and application(s)
- Centralized configuration and management of applications
- Ability to securely access the environment from all devices without punching a hole in the corporate firewall (SAP BTP Security Community)
- Options to federate out applications and processes that are defined and managed in cloud but run locally at the edge (aka fog) layer
These value drivers are important because in the past the deployment of new software meant that there was a large amount of overhead to not only manage the initial setup, but also to control the variations and configuration nuances that occurred over time. These expenditures are the hidden cost of software that are often spread across multiple departmental budgets in order to provide full coverage and are often overlooked when talking about legacy compared to SaaS applications.
So how does this translate then to manufacturing operations? To understand this, we first have to take a closer look at what are some of the areas where software generates the most overhead for organizations to manage over time. Since they vary across each manufacturing location and the heritage of how it has matured over time you can expect that there is homework to be done first. These questions are a good start for what to tackle up front when discussing business investment priorities and target locations for the investment into updating processes, methodologies and the technology that supports them:
- How many manufacturing locations have software over 5yrs old?
- Of these, how many are managing important compared to critical tasks?
- How much technical debt has been incurred over time for both homegrown and commercial software?
- What are the supporting technologies required for them to operate and are they also separately licensed?
- What kind of staffing is required at each site to simply keep the lights on for hardware and infrastructure management?
- What is the value of the current system and how long will it keep its value for the manufacturing site?
- Does it have a role specific for the site or does it influence the broader organization and how?
- What is the level of effort required to report across multiple locations and to maintain these reports over time?
- How well coordinated are engineering, planning, logistics, operations, quality, and maintenance teams?
With these answers fresh in your mind there is likely some growing interest in how exactly this would work to fit your needs. The good news is that we (SAP) have already been thinking about this for some time now and building out our SAP Business Technology Platform (aka SAP BTP) and SAP Digital Manufacturing Cloud (aka SAP DMC) to align to all of these concepts. Early on in our development lifecycle process we identified the development of a SaaS MES and played an instrumental role in the design and architecture of our SAP Digital Manufacturing Cloud. When we (SAP) constructed the business case around this we focused in on the value of cloud and the practical needs of operations to ensure that whatever application processes that we could deliver had a strong foundation in the value of SaaS. We made sure that we could address complex manufacturing needs for Discrete, Process (initial focus on Batch), and Hybrid (Combination of Process & Discrete). We made sure that we could federate out these processes to ensure reliability along with scalability provided when transactional load is federated out. Lastly, we made sure that the data model and structures were common across all of supply chain and not just focused on a single plant/site of operations. This enables not only consistency in configuration but also in the way operations are reported (For more details on analytics see this blog Enterprise Analytics for your Supply Chain).
There is a lot still to do and we are continuously innovating (See SAP DMC Roadmap), but we have also come a long way already (See SAP DMC Documentation)! If you comments or questions please feel free to leave them below for me, they are always appreciated.