Managing information to enable and drive operations has become a critical ability in today’s ever-faster and more complex business world. Increasingly a worn buzzword, the term “digitalization” has emerged as a response to this need.
Still, the value of an unbroken digital thread, i.e., a seamless automatic exchange of information, will not disappear. Companies that can become adept at information management will be armed with a powerful competitive advantage.
Digital Transformation has the reputation of being both resource and time-consuming, and many companies are hesitant to even embark on this journey. These organizations need help understanding the value of Digital Transformation and answering why they should do it.
In this post we will discuss how the value of digitalization of architecture data management can be quantified. But first, let’s start with some background of Product Architecture and why the data needs to be managed.
Product Architecture is how products are composed. Architecture has little to do with building design in this context but is a term for an effective structure. There are about as many definitions of Product Architecture as there are product-owning companies. In this post I will use Product Architecture to describe how a company’s products are built, a common base that enables sharing solutions, structures, parts, etc. The product architecture will also be very important for downstream functions from R&D, such as sourcing, production, and sales, as well as for upstream functions such as marketing and product planning. A good architecture will benefit all parts of the business by allowing for efficiency, flexibility, and agility. Other terms that may touch on the same subject that are often used are Product Platforms, and Modular Systems.
Product Architecture development entails the creation, systemization, communication, and storage of large quantities of information. The data covers customer and market knowledge, technology and engineering data, pricing and functionality data, and cost and production lead-time data. All this data is necessary to enable and drive the business processes that are the bloodstreams of an enterprise.
To claim we have documented the Product Architecture, we at least need to know what it consists of. These are the building blocks, or modules with variants, that can be used to build products. However, the architecture also needs definitions of how these blocks fit together, the interfaces. Otherwise, we wouldn’t be able to exchange one block for another. Lastly, we need a description of how a product can be combined from the blocks. A structure with rules that state, for example, that a car has four wheels and that wheels on the same axle must share a diameter.
A minimalistic representation of a Product Architecture could be expressed by modules, module variants, interfaces, product structure, and configuration rules.
However, a lot of metadata can be added to document different aspects of the architecture, such as customer needs, product performance, market strategies, product families, projected sales volumes, etc. Data that would support confident decision making over the life of the product architecture. Because one thing is for certain, the product architecture cannot remain constant – if it does, its value quickly diminishes – and that means that proper governance of change must be in place to succeed.
Often this type of information is largely unstructured, spread throughout different systems, documents, and in many cases, in the mind of a few critical employees. Let’s call this a document-driven company while discussing the converse—a data-driven company.
The document-driven company is characterized by its manual information exchange across siloed company functions. Information shared between and even within functions of the company is stored unstructured in documents, spreadsheets, and even slide shows. Often there is not a clear structure where information is saved and how it is versioned, or access controlled. Of course, this perpetuates manual and redundant work, and low data quality.
This method may meet the needs of one group. Still, its faults become more apparent when communicating information from one company function to the other since, typically, documents are managed with manual information exchange across company functions. This way of working is illustrated by the “washing lines” in the graphic below that convey the files from one function to another.
Document-driven company: isolated functions have their processes with supporting IT solutions, sharing data ad-hoc via e-mail, and unstructured office documents
On the other hand, the data-driven company has connected the different functions, exchanging data seamlessly by using the same source of truth. Data is structured, versioned, and access controlled, and various systems consume the same master data via automated integrations.
Digitalization is about knocking down the walls between company functions and connecting the IT solutions within each organization to each other.
Data-driven company: connected with seamless exchange of up-to-date information
However, achieving a connected company with a seamless exchange of information takes time and effort. History is full of delayed and costly integration projects. Failure can occur because of technical snags, but more often, it is the absence of a common way to define and communicate data along business processes and across company functions that is the downfall. Every enterprise information system has its way of structuring and expressing data; it is hard to transform the data format from one IT solution to another. It is like speaking different languages while trying to understand complex matters.
Hence, it is vital to develop and agree on one language, i.e., a common information model. Only then can a genuinely unbroken digital thread of product architecture data be established.
The information model for Product Architecture is the common language needed to communicate along business processes and cross-company functions. The model is enriched with data necessary to drive a specific process, which makes it possible for upstream and downstream processes to consume and communicate their data.
But what is this unbroken digital thread worth? Investing in digitalization requires estimations of the value gained. The value of the productivity improvements arises across value streams and company functions, both in what is typically described as a direct and indirect cost.
Estimating the value can be broken into four key steps. This structured way of calculating the value also reveals what actions are necessary for improvement.
The first priority should be creating an overview of what functions will interact with Product Architecture Data. Analyze existing process maps, or if these are not available, use generic process maps for typical business processes.
Ask process owners to confirm existing process maps or, if necessary, adjust existing or generic processes to reflect reality. Often the map and real life are not always aligned.
Create input forms based on the process maps to establish a baseline and fundament for the interview.
Gather personnel-related costs to execute the processes in scope. This research can typically be done pro forma together with controllers. Together with process owners, allocate relative resource consumption per process and process steps and establish the critical path per process.
Analyze effort reduction for each process step by asking, “How could seamless automatic exchange of information, providing accurate, readily available, easy to use and communicate data, reduce the manual effort in this process step?”
Likewise, analyze lead time reduction for each process step by asking, “How could seamless automatic exchange of information, providing accurate, readily available, easy to use and communicate data, reduce the lead time in this process step?” Also, identify what potential roadblocks may impede automation and how these can be removed.
Combining the baseline cost for executing the process, together with the effort reduction per process step, make it possible to monetize the value of improved digitalization of the Product Architecture data management. This calculation also reveals inefficiencies in process execution because of poor information.
4 Steps to Estimate the Value of Streamlined Product Architecture Data Management
As with all cross-functional business process analysis work, it is essential to frame the analysis and secure support in the evaluated organization. Agree with the management team on the scope of the study: organization(s) to be investigated, the processes to be analyzed, expected outcomes, and delimitations, i.e., what is NOT included or studied.
Secure executive support across company functions:
Often there is a clear benefit in securing external guidance for this type of work. An outside view, combined with your internal experience, is often the most efficient way to reach change and overcome internal hurdles and politics.
Best of luck to all digitalization champions on your journeys, whether you are just beginning or in the middle of it. Please get in touch if you want to understand how to get started with your project!
+46 8 456 35 00
johan.kallgren@modularmanagement.com
An introduction, based on first-hand executive experience, to how to connect a company by Architecture enabled digitalization.
A guide to business process mapping. Process mapping is a vast topic with an endless number of guides and approaches. Consider finding sources relevant to your needs, and use methods already in place within your organization.