Why do software companies buy software

Business software

Companies that strive for long-term success in the market will in fact transform themselves into software companies in the next few years. At least that is the prognosis of many gurus who should actually know. The mantras are garnished with robust quotes à la Software is eating the world. But what is the thesis behind this prophecy?

How so? Why? Why?

Regardless of whether it is in production, logistics or the service sector: For many years we have used the thumbscrews to optimize costs in every sector. For almost three decades it was not primarily about innovative business models, customer experiences or new markets, but about cost efficiency. With the increasing use of machines and computers, we have outsourced more and more processes to these metal boxes. And we humans carried out the residual waste in processes that the standardized machine processes could not handle.

In order to differentiate yourself on the market, it is no longer enough to implement standard processes for all machines and systems such as ERP, CRM or production planning. A successful company needs its own profile.

So just software companies after all?

It is no longer enough for people to do the putty between the different process worlds. In the future, we will also use machines and computers, i.e. software, for the system-connecting processes. In order to react quickly to market requirements and to keep the core know-how in the company, most companies will create, maintain and operate these software systems themselves.

Managers must learn to not only share and / or develop their requirements for change with the people in an organization; you will have to have these poured into code as well.
These aspects mean that almost every company needs people who create software in the broadest sense - just as the software companies used to do. In this respect, the thesis that almost all companies become software companies is correct, but it does not get to the heart of the matter.

Because this logic does not mean the skill that a few people in the company program a little on a project basis and create a new software update once or twice. Rather, it is about aligning the entire company to a version and release-based, agile approach.

The release heartbeat

It is about an organization in which a product manager as an intermediary between technology, customers and business bundles the requirements. These are then implemented by product owners in small agile software teams every two or at least every four weeks as a new release.

It's about the logic that all customers are using the same version of the processes because the deployment is done in flexible models. And the point is that this release-centered way of thinking becomes the heartbeat for all other areas such as sales, support or logistics. Interestingly, not even all traditional software companies work like this today. And the mega buzzword "agile organization" does not hit the core either. Because "agile" is just a tried and tested option for implementation; but not the core of a release and feedback-supported company organization.

With this in mind, it makes more sense to see the release-supported heartbeat of two or four weeks as the core of every successful company for the future. The competence of software development as an agile approach with a feedback culture is another important aspect.

What does this mean for the corporate culture?

Departmental thinking is established in traditional organizations. These perform their specialized tasks with a certain degree of autonomy and interact with each other via clearly defined interfaces. This picture changes significantly in a service-oriented structure. The basic processes of the actual value creation run in machines; either in production machines or on computers. These machines produce their output almost independently of human interaction.

However, people are needed to plan and implement changes to machine processes. And this is exactly why a continuous procedure has been established in the logic of releases (every x weeks) that are produced in sprints. This means that all departments are subordinate to this change heartbeat. And: In this approach, communicative skills are becoming more and more important for almost all employees; working in a quiet little room within a department is becoming increasingly unlikely.

With this approach, the concepts of the hated matrix organization finally come to an end. Because these result from the fact that people are needed in the implementation processes to replace machines. On the other hand, the same people should carry out change projects in companies. No wonder this contradiction has caused most organizations to collapse in recent years.

In my remarks, I have used the term agility as little as possible because it does not get to the heart of the matter. Agile methods are definitely a tried and tested means of establishing the new release heartbeat in a company.

In this way, the release cycle becomes a regulating heartbeat

Many companies have large digitization initiatives, workshops on agile methods or design thinking seminars. And after that, all employees in their departments continue to work and maybe try to apply some of the new skills. But usually it doesn't go any further. This is precisely because we are still sticking to our tried and tested procedural models for waterfall planning; with project plans with a duration of several years and at least 80-page concepts.

If we don't manage to establish the heartbeat of the x-week release cycle and organize all of our planning in sprints, then even the most sophisticated agile methods will be of no use. Whether you need a minimal team of three or 25 in an organization depends on the complexity of the products and services. If resources are scarce, this also speaks in favor of keeping the scope as small as possible so that this heartbeat can unfold with all its regulating power.

... and the business model level also benefits from this

As a fan of digital as-a-service and platform business models, I would of course like to see changes at the business model level as early as possible in a change process. However, I have observed that the initiatives and projects often become so large and cumbersome and that the new digital heartbeat cannot develop - too many people are busy with topics that are far too fundamental.

Based on this experience, I have changed my mind and can imagine starting a restructuring process without clarifying how to change the business model. Because the regulating power of the release heartbeat on an entire organization should not be underestimated. (bw)