How Barilla Created a Social Media Style App to Improve Efficiency - Build What's Next
Case Study

How Barilla Created a Social Media Style App to Improve Efficiency

5649

Of your peers have already read this article.

3:30 Minutes

The most insightful time you'll spend today!

By consulting factory workers about their needs and aspirations, Barilla created with Google Cloud technologies a successful social-media style app to improve efficiency on the production line.

Google Cloud Results

  • Replaced conflicting, time-consuming paper logs with a near real-time, transparent app
  • Scaled rapidly and easily to accommodate new teams thanks to Google App Engine
  • Enables photographic and video communication to replace confusing text
  • New factory solution rolled out in just 15 days

In 1877, Pietro Barilla set up a small bakery to make pasta and baked goods for the people of Parma, Italy. Today, Barilla applies its 140 years of baking knowledge on a global scale, with six major manufacturing sites in Italy and an international network employing over 8,000 people. As the world’s leading producer of pasta, Barilla knows that when it comes to making quality food, great communication is key. That’s why the company plans to become a completely digital, looking to technology to improve the way it works.

Teams at the Barilla factory in Cremona work along a production line more than one-kilometer long, staffed by three shifts of workers a day. When one shift handed over to the next or requested machine maintenance teams, they used paper notebooks and unofficial instant messaging to communicate. That meant there was no authoritative, real-time record of events, communication was messy, oversight was poor, and teams had to hold daily morning meetings to synchronise notes.

Barilla worked with the Google Cloud Partner Injenia to create a solution, beginning with a consultative process on the factory floor.

“We had the idea to to start from the bottom and work up,” says Cristiano Boscato at Injenia. “Barilla’s top staff were brilliant about letting us do it. Eight of us from Injenia spent months on the factory lines with Barilla workers, collecting ideas on Google Docs, making presentations with Slides and collecting feedback with Forms. The CollaborAction app we created is the result of an amazing partnership.”

Co-designing a team social network

“Everything at the Cremona plant was managed offline, with paper,” explains Alessandra Ardrizzoia, Digital Engagement Senior Manager at Barilla. “Workers on the line would track events in notebooks, the shift leader would have another notebook, and the leader of the maintenance team would have yet another notebook. Everybody wrote their own text description of events, so there would be mismatches in the information going around.”

To resolve this, teams would meet at 8:30am every day to reconstruct a consistent narrative. In addition, machine maintenance workers were already using instant messaging to communicate with the line. Barilla and Injenia looked for a solution that could deliver a searchable, single version of events, with the ease of use of a mobile messaging application.

After consulting factory workers for ideas, Injenia created CollaborAction, a custom-built app that brought G Suite collaboration tools together on an Google App Engine platform, using Google Cloud SQL to index files. Google+Google Drive and Hangouts were not only highly available and easy-to-use, they also “helped with fast adoption, with interfaces that workers could already relate to.” Meanwhile Google App Engine enabled the Injenia team to deliver updates and new versions at speed, as part of a feedback process with workers who offered suggestions through a link to Forms embedded in the app.

Google+ provides an intuitive social media dashboard that workers felt comfortable with. Now teams use company tablets placed at intervals along the line to log in, report issues to other teams, photograph problems, schedule maintenance, give status updates through Hangouts chat, and have visibility on the whole process as it takes place.

“Everyone in the Cremona plant was really happy with the new social collaboration process. Because they were involved in designing the solution, they felt involved and really engaged with the process,” says Alessandra. “And now that everyone is aligned with CollaborAction, all the work in the plant is more effective. They are more agile and can use their time in more added-value activities.”

Optimization and a national roll-out

Created in Cremona, now CollaborAction connects over 1,000 users in six of Barilla’s factories in Italy. “The pilot at Cremona took one month, and adoption has been easier and faster in every plant we’ve taken it to,” says Cristiano. “We have another five or six plants more, and it takes no more than 15 days to introduce. That’s incredible.”

Because CollaborAction is a mobile app built on Google App Engine, scaling to meet new demand has been simple. Now maintenance teams use the app on smartphones, line workers use it on tablets, and shift leaders use it on laptops, so the entire team is aligned in close to real-time on a single version of events. And now teams communicate with video and photographs as well as text, there’s less room for confusion, as Alessandra explains. “It’s no problem understanding what’s happening in a video or picture, compared to a message that just says ‘something is going wrong.’ On a production line, where one part leads into the next, that speed makes a difference, and means we don’t have to throw as much food away when something breaks down.”

“Now we’re collecting feedback from all of the plants using CollaborAction and using it to create a standardised solution that we can apply across all of our plants,” says Alessandra. “We’re side-by-side with the workers in that sense, trying to address their needs with new features. It’s a way to make the workers feel like part of the solution, and that the app represents their needs and their voice.”

Solving a universal problem

By the end of 2018, Barilla and Injenia aim to have deployed CollaborAction to 2,700 employees at 18 factories worldwide. Barilla has already collected more than 50,000 posts with the app, including around 20,000 photographs and videos, and is now considering ways to apply Cloud Machine Learning Engine to create a maintenance chatbot or direct IoT connection with machinery.

“CollaborAction hasn’t just made our maintenance processes faster and more efficient, its also exponentially increased the knowledge and understanding employees have about their work,” says Alessandra. “It’s improving team spirit, too, such as when employees use CollaborAction to arrange to play soccer. It’s become the main communication tool for the entire plant.”

Research Reports

Ensuring Reliability in a DevOps World: Insights from the 2022 State of DevOps Report

2682

Of your peers have already read this article.

3:30 Minutes

The most insightful time you'll spend today!

The 2022 State of DevOps Report highlights the importance of reliability and SRE in driving business success. Find out how to improve your organization's performance and stay ahead of the competition.

When a software change is deployed — after being designed, coded, tested, packaged, and tested some more — a journey comes to an end. At the same time, a new journey begins: your customer’s relationship with your service. It’s here, in the domain of operations, that abstract risks like launch schedule slippage give way to tangible risks like lost revenue, degraded trust, and tarnished reputation. Only when it’s available to users can software contribute to (or threaten!) the success of your organization. And so, throughout the past several years, the DevOps Research and Assessment (DORA) project has incrementally deepened our research into the reliability of services, through and beyond deployment, into ongoing operation.

Reliability is a broadly defined term, which refers to a team’s ability to meet their users’ expectations — for software services, it may encompass aspects of availability, latency, correctness, or other characteristics that influence the consistency and quality of user experience. Google’s practice of Site Reliability Engineering (SRE), which has been embraced and extended by a global community of reliability engineering practitioners, is an approach to operations that prioritizes user-oriented measurement, shared responsibility, and collaborative, blameless learning. Starting with the 2021 Accelerate State of DevOps Report, we began asking survey respondents detailed questions about reliability engineering in their organizations. We continued and expanded our investigation in 2022, and found further evidence that modern reliability engineering is widespread: a majority of respondents report that they employ SRE-style practices. With this extensive body of data to draw from, this year we pushed further into analyses of the impact of reliability and its interaction with other dynamics present in our model of technology’s influence on organizational success.

Reliability matters

When reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes

Reliability is more than beneficial: it’s essential. As in prior studies, we find that software delivery performance (as measured by the “four key metrics” of change lead time, deploy frequency, change failure rate, and failure recovery time) is predictive of organizational performance. However, this year’s analysis revealed a previously unseen nuance: the influence of software delivery on organizational performance is predicated on reliability. When reliability is high, high-performance software delivery predicts better outcomes for the organization. But when reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes. This affirms a long-held belief among reliability engineers: “reliability is the most important feature of any system.” If a service or product doesn’t meet its users’ reliability expectations, it’s counter-productive to rapidly ship flashy new features, because users can’t properly experience them. Software delivery relies on a foundation of reliability to create value.

https://storage.googleapis.com/gweb-cloudblog-publish/images/dora.max-900×900.jpg

Reliability is a journey

Any experienced leader will tell you that progress is rarely linear: even with a discipline like SRE, widely practiced and with demonstrable benefits, the path to success is unlikely to follow a straight line. DORA describes the “J-Curve” of organizational transformation, a phenomenon in which durable success comes only after setbacks and lessons learned. This year, we compared the depth of teams’ reliability engineering practices to their impact on the services they provide: will an investment in SRE produce greater reliability? The answer is yes, but with a significant caveat: not at first. Comparing reliability outcomes across a range of levels of SRE adoption, the J-Curve is plainly visible. A team which practices SRE only lightly — at the beginning of their SRE journey, perhaps — is likely not only to not benefit, but to regress in terms of the reliability experienced by their users. However, after these practices have more deeply permeated, an inflection point is reached and we see strong reliability benefits from continuing to grow the reliability engineering capability.


Knowing that it will likely take time to realize the benefits of adopting SRE, it may be tempting to start the process as soon, and as broadly, as possible. But we offer a note of caution here: organization-wide cultural transformation initiatives typically fail from overreach. We studied this and reported findings in a previous report. And even if you manage to beat the odds and fully adopt SRE across multiple teams simultaneously, the cost may be unacceptable: the setbacks in reliability that you are likely to experience early on, amplified across an entire organization all at once, could have catastrophic consequences. Therefore the SRE principle of gradual change should also be applied to the adoption of SRE itself.

Reliability is about people

Reflecting back on over a decade of SRE practice and theory, the Enterprise Roadmap to SRE underlines the importance of culture, suggesting that Site Reliability Engineering is in fact emergent from culture. Tools and frameworks are important; language is essential. But only a trustful, psychologically safe culture can support the environment of continuous learning which enables SRE to manage today’s complex, dynamic technology environments. DORA’s research in 2022 demonstrates the interplay between culture and reliability: we found that “generative” culture, as defined by the Westrum model, is predictive of higher reliability outcomes. And reliability has benefits not only for a system’s users, but for its makers as well: teams whose services are highly reliable are 1.6 times less likely to suffer from burnout.

Got a story to share about your DevOps journey? Submit it to Google Cloud’s 2022 DevOps Awards by January 31, 2023!

Whitepaper

Application Modernization Made Easy

DOWNLOAD WHITEPAPER

5694

Of your peers have already downloaded this article

5:30 Minutes

The most insightful time you'll spend today!

Modernizing apps on the cloud isn’t an “all or nothing” decision. Businesses want the option to modernize on-premises or choose multi-cloud solutions that meet their needs. That’s why we created a new solution for running apps anywhere – simply, flexibly, and securely. Embracing open standards, Anthos lets you run your applications, unmodified, on existing on-prem hardware investments or in the public cloud. So that you write once and deploy anywhere.

Download this report and find out how to:

  • Decouple infrastructure and applications with containers and Kubernetes
  • Decouple cloud teams from one another so they can work independently
  • Meet the challenges of microservice management using service mesh
  • Implement a zero-trust security model to enforce more granular controls while maintaining a consistent user experience
E-book

Scaling Microservices- Why Microservices Need API Management

DOWNLOAD E-BOOK

4123

Of your peers have already downloaded this article

10:32 Minutes

The most insightful time you'll spend today!

While microservices are lauded as catalysts for speed and scale, the conversation is incomplete if it does not include APIs. Without APIs, microservices cannot be securely, reliably, and adaptably scaled across an organization or to outside partners. Moreover, because these APIs and their microservices are meant to be widely consumed and reused, it’s not enough for companies to merely create the APIs and move on. Rather, the APIs should be continually managed so the business can control how its microservices are accessed, generate insight into how they are used, and encourage reliability of its services.

As microservices grow beyond their original use cases and are being leveraged to share important functionality throughout the enterprises and even with external partners, the problem that arises is how this sharing creates challenges for teams trying to secure, monitor, understand usage of, and fully take advantage of microservices.

In this eBook we explore how leading enterprises are facing these challenges head-on and scaling their microservices strategies. Learn how APIs make it possible for microservices to be securely, reliably, and adaptably shared, and how an API management platform enables enterprises to ensure that they maintain control over their microservices as consumption grows.

Blog

Release of Go 1.18 is A New Milestone for Development of Secure Apps

3203

Of your peers have already read this article.

1:30 Minutes

The most insightful time you'll spend today!

Go, the go-to language for multi-core computing world is behind many Google products. Go developers community globally has grown into network of over 2 million users. With the release of Go 1.18 read how it is a milestone for building secure apps!

On March 15th, the Go team announced Go 1.18 GA, the latest release of the Go programming language. The culmination of over a decade of design delivers the features our developers demanded: generics, fuzzing, and module workspaces. With this release, Go becomes the first major language to integrate fuzz testing into its core toolchain without using third-party support, further establishing Go as a preferred language for developing secure applications.

Go was created at Google in 2007, designed to help developers build fast, reliable, and secure software. Unlike traditional languages, Go was built for the modern multi-core computing world. Go has emerged as a modern language for developing cloud applications, services, and infrastructure. Today Go powers several of Google’s largest products, and is used by many customers to scale their businesses. Organizations big and small love Go and the community of Go developers, known as “gophers” has grown into a global network with over 2 million users worldwide.

Using the power of Go in the Cloud


When looking at the public repos, over 75% of CNCF projects including Kubernetes are written in Go and 10% of developers are writing in Go worldwide (as of May 2021). Google delivers high performance infrastructure to run key, cloud native, Open Source projects. Our modern cloud infrastructure is based on Kubernetes at its core and our strong support for Istio and Knative have formed the base of some of our leading services like Google Kubernetes Engine (GKE), our managed application platform with Anthos, Cloud Functions, and Cloud Run. Google uses Go extensively for a wide range of applications from our indexing platform that powers Google Search, to the server side optimizations that power Chrome’s 1B+ users, to the infrastructure on which Google cloud is built.

Release Highlights


With this new release of Go 1.18, Generics are the biggest change to Go since the language was created. Go developers told us that they feel that Go lacks critical features, with generics being the main missing piece. With Go 1.18, new and existing Go developers can take advantage of the productivity, performance, and maintenance benefits that generics can bring. We’ve already begun to see the new kinds of libraries and projects gophers are building with generics in its short beta period, and expect this creativity to grow as time goes on.

This Go release also brings native support for fuzzing. Fuzzing is a type of vulnerability testing that throws arbitrary data at a piece of software to expose unknown errors and is emerging as a common testing scheme in enterprise development. Go is now the first major language to provide fuzzing support with no third-party integrations necessary, allowing developers to start building secure software with minimal additional cost. Go’s innovative approach to fuzzing can provide not only security for the current code but also ongoing protection as code and dependencies evolve. With attacks on software becoming more common and complex, vulnerability detection can be a critical part of the enterprise development lifecycle, and Go’s fuzzing capabilities catch vulnerabilities earlier in the lifecycle.

Build securely using Go


At Google we are helping to make Open Source software secure. Open source software is a connective tissue for much of the online world. At Google, we’ve been working to raise awareness of the state of open source security and are committed to helping secure the software supply chain for organizations. Go has been designed to create secure applications, helping to minimize risk as much as possible. Go applications compile down to a single binary without local dependencies. It’s not uncommon to see an application built using only the standard library, or only a couple well-vetted Go dependencies. Go’s dependency management uses tamper-evident transparency log, with built in tooling that helps ensure your dependencies are what you can expect. Go has native encryption, which is used across much of the internet, including key components of Google. Go even supports distroless containers, where there are zero local dependencies to worry about. Google Cloud products like Cloud Build, for CI/CDand Artifact Registry, for container management, and have direct access to Go’s vulnerability database and can provide you instant warnings about security threats.

“At Google we are committed to helping to secure the online infrastructure and applications upon which the world depends. A critical aspect of this mission is being able to understand and verify the security of open source dependency chains. The 1.18 release of Go is an important step towards helping to ensure that developers are able to build secure applications, understand risk when vulnerabilities are discovered, and reduce the impact of cybersecurity attacks” said Eric Brewer, VP Infrastructure, Google Fellow

This launch is a significant milestone for Go that helps developers from around the world build more performant and secure applications that run on any infrastructure. For more information on this release and how to get started with Go, please visit.

Case Study

How Experian Transformed its Business by Using APIs

3752

Of your peers have already read this article.

3:00 Minutes

The most insightful time you'll spend today!

Experian, a traditional credit bureau, transformed into a true technology and software provider by leveraging APIs to gather, analyze, and process data in ways that other companies just can’t.

Chances are, when you think of Experian you think of a traditional credit bureau that provides credit reports. But Experian has transformed into a true technology and software provider. We gather, analyze, and process data in ways that other companies just can’t. Businesses use this data to make smarter decisions about credit and lending, as well as to prevent identity fraud and crime. We’re also able to use this data to help individuals take financial control of their own lives and access all kinds of financial services with products like Experian Boost.

Transforming data delivery, transforming the enterprise
A big part of our digital transformation has been based on our API program. We approached APIs with a concrete goal in mind. We knew exactly how we wanted to transform the business, and we had a set plan to achieve that. For us, this meant establishing an API center of excellence as a first step. It’s sole purpose was to enable the business units to create their APIs quickly and correctly, then apply them properly. We then went out to the business units one by one so that we could train them to build their APIs in a customer-friendly way. We taught them the entire API process of building, giving access to developers internally and externally.

This approach is fundamentally different from previous ones. As far back as the 1990s, our customers connected to us via software applications installed on their systems. As technologies evolved, our services to customers evolved, and we began supporting XML-based transactions and custom integrations with our partners. Some of these integrations actually included VPNs rather than going through HTTP connections. We did custom database schemas, one-off processes, and all kinds of custom development. 

This meant that we had a team just for our IT system processes. This team kept growing as Experian continued to acquire new companies. Each acquisition brought a new way of doing integrations and business. We had a real challenge in standardizing development practices, which led to a lot of isolated environments inside the company. We had disparate data repositories and non-standard client conductivity, which hampered innovation.

Responding to customer demand for APIs
When we first started, we had some concrete goals. We wanted to grow our ecosystem, develop a massive reach for transaction and content distribution, power a new business model, and drive innovation. Basically, we wanted to use APIs to transform our business into a platform, and we wanted to build an ecosystem that leveraged this API platform to develop new solutions. 

Our leadership also understood the importance of delivering information to our customers in the way they wanted to consume it. Our customers had told us that they didn’t want software, they just wanted access to the data—and APIs are the easiest, most secure way to grant that access. 

The Apigee API management platform as an enterprise solution
We knew we needed an API management platform to enable this step forward. In addition to the documentation and discoverability, we also wanted a place to create APIs fast, and where we could get visibility into usage and other metrics. The Apigee API management platform from Google Cloud offered all of this, and more. From the robust feature set to advanced security to the developer portal to analytics – Apigee provides us everything we need to run an enterprise-class API program.

Now that we have our API program up and running, integrations no longer take months. In some cases, it’s just a matter of minutes or seconds. Customers can simply look at our documentation on how to invoke APIs and begin consuming data in seconds. We started with this new model in our three largest markets: North America, the United Kingdom and Brazil. Later, we rolled it out to Singapore and Australia, while deploying an on-premises platform for some of our North American business units that needed to provide their APIs internally only. Next, we went to EMEA. At this point, we’ve deployed Apigee company-wide, giving us a flexible deployment model that maintains a centralized platform and processes.

We continue to evangelize the program today, and we recently conducted a workshop with the Apigee team to train our EMEA business unit and get them onboarded to the platform. They were able to start developing API proxies right away, and they’re set to go into production with as many as nine of them. We also went live with three developer portals, which we call API hubs, in North America, the United Kingdom, and Brazil. 

As we expand, we don’t want to keep building up different developer portals for each region because then we’re going to have too many. Alternatively, we plan to combine them into a single global developer portal that will allow users to select geographies of interest where they’ll be presented with relevant information.

Experian continues to evolve the types of products and services we offer. Thanks to Apigee, we have the flexibility, security, and technology to keep innovating and providing value to our business and our customers.

More Relevant Stories for Your Company

Blog

A CIO’s Guide to the Cloud: Hybrid and Human Solutions to Avoid Trade-offs

What do CIOs and CTOs deliver for the company? If you said “technology,” that’s just the beginning. According to their research, McKinsey found that 85% of CIOs and CTOs interviewed in the spring of 2019 said they were essential for at least two of the three most common CEO priorities—revenue

Blog

How Kubernetes is enabling digital transformation for retailers

Retail organizations constantly face financial pressure to increase sales while maintaining profit margins. Digital commerce creates new opportunities and a more competitive landscape for retailers by allowing them to reach a global customer base online, but it also exposes them to competition from larger online retailers. To be successful in

Case Study

How Macquarie Democratized Digital Banking with APIs

Google Cloud Results Enables the speed and agility required to build open APIsConnects over 1 million customers through Apigee digital touch pointsHelps enable a range of digital banking and commercial partnerships1billion API requests served annually In 2016, Macquarie launched a new digital banking experience that was based on empowering customers, creating personalized

Research Reports

Dataflow Guarantees 50+% Increase in Developer Productivity and Infrastructure Cost Savings: Read More

In our conversations with technology leaders about data-driven transformation using Google Data Cloud -  industry’s leading unified data and AI solution - , one important topic is incorporating continuous intelligence to move from answering questions such as “What has happened? to questions like “What is happening?” and “What might happen?”.

SHOW MORE STORIES