Part 4: Why Product Owners aren’t System Owners, and some about eco-system-thinking

In the last post we discussed why the stakeholders should not run their own digitalization projects, and why we need Digital Product Owners to do it instead.

In this post we go a step further and will discuss why the way traditional companies divide the responsibility regarding digital investments is inefficient. This ties neatly into the previous post since this post will further explain the role and responsibilities of a Digital Product Owner (normally just called Product Owner, but since a lot of product producing companies already have product owners for their sellable products, I here want to make a distinction).

The most common way for traditional companies to define ownership over an implementation or development project in the digital space, is to base the ownership on systems. Hence someone in the organization is the “owner” of the ERP system, another person is the owner of a CRM system etc.

As with a lot of the characteristics for traditional companies, this may seem logical, but is in fact usually a mistake. 

There are several reasons as of why this is a bad idea, and here are a few:

• If we take a look at what the systems are there to support, information management or transaction execution are only part of their function. In fact, the systems are there to support processes of various kinds. And as previously discussed in this series of articles, processes span more than one department and usually also more than one system.
  • Hence; a system owner cares only about the system as such, but takes no responsibility for the processes they are there to support if these processes span more than one system
• A system, no matter how powerful it is, cannot support all business processes on it’s own. Instead we need to see each monolithic system as part of a bigger ecosystem where various components need to work in harmony in order to give the organization the highest value of the investment we do.
  • Hence we usually need a mix of systems, components and services to achieve the highest possible level of operational excellence.

The above leads us to start thinking in ecosystems instead of systems: When we start to realize that the systems we have to our disposal are all vital part of a greater eco-system, where we can use technology to enhance the usage and benefits of the individual components, we soon see that the the whole is greater than the sum of its parts.

Companies who want to switch focus from System Based Digitalization, should turn their current approach towards Process Based Digitalization. I realize this may sound floaty, so let me give an example.

Example: Let’s say we want to automate the Invoice handling and achieve 80% digital invoices (non PDF), and introduce touchless invoices when that is possible.   This means we need to look at various ways of receiving the invoices; though EDI, APIs and through some functionality in a collaboration portal where less advanced suppliers can fill in a form or login and upload the invoice. It also means we need to build a flow for clarification management, native components for evaluating incoming invoices against various data sources to see if we can pay the invoices automatically, and we will need interfaces for this process. An ERP system will definitely play an important part here but will probably not make up more than about 30% of the total development needed. As you can see this means that someone solely responsible for ERP configurations and development will not be able to solve such a task. In this specific case you could argue that someone in accounting could be the process owner, which might true for this example (however, also legal, controlling and fulfillment may also have a stake here), but we cannot build structures and project methods around exceptions, and most processes involve a number of stakeholders in the daily operations (see part 3 regarding this sopic). This means that we need to “cut the elephant” in a different way, where the technology choice is less important than the process improvements.

As discussed in part 3 in this series, it also means that we would benefit from moving the responsibility for digital improvements from stakeholders in the day-to-day operations, to a central Digital Product Owner organization, with strong ties to the stakeholders. 

Hence, the Digital Product Owner becomes the servant of the stakeholders, and the funnel to the engineers/developers, who are  responsible for bringing the ideas and improvements to life.

Schematically you can picture it this way:

After an implementation project, there will of course be need for changes, bug fixing and other maintenance, and here different schools in Agile promotes different solutions.

Some say that the responsibility also after rollout should stay with the initial product owner and the team of engineers that once upon a time did the development.

I do not agree. A Digital Product Owner, and the engineers to her disposal, will constantly get new challenges to solve for other processes that needs improvement.

If this team already has launched 2-3 products, and now are to move on to the next prioritized area of improvements, they will soon find themselves in deep trouble regarding their priorities; Should we spend time fixing a bug in an already rolled out product, or should we spend time to improve another process with poor system support?

Since the aim for the Digital Product Owner is to rapidly bring value to the company and the various stakeholders, in order to achieve Operational Excellence, I promote a different way to handle already rolled out products:

We introduce a DevOps organization (see part 3), that takes care of 2:nd level support (bug fixing) and sees to system maintenance, upgrades etc. 

If we have a more severe bug (3:rd level support/bug fixing) it may be justified to send this to the team that originally built the product (process support). Also functionality changes or other needed development of the product, should be done by the original team, but apart from that they should be relieved form the daily maintenance so that they now can focus on the prioritized tasks, to further improve the company’s operational processes, customer experience, or likewise.

As a matter of fact, this approach fits perfectly with an Agile mindset also in other ways: 

When we see the implementation of a system as its own goal, as opposed to seeing the system as tool to achieve better processes, it is very easy to slip into a waterfall methodology, where the workload for the stakeholders becomes unbearable and where we forget to think about the four “W:s” and the one “H”. See part 1 and part 2 of this series for more information.

In part 5 of this series I will give some basic insights in how to actually work agile, with some tips regarding how to implement the methodology step-by-step.