When I gave an interview to the logistics company “bayernhafen” last month, the discussion came up among other things on the topic of inhouse software teams. I argued that it was incumbent upon companies to use technology to design processes and the user experience as cost-effectively and simply as possible. The add-on, on the other hand, would be to build internal software development teams to venture new models and experiments.
This caused confusion. I was asked, for example, whether I think that one should develop all E-Business software internally. And whether standard software is an outdated model. I find both of these ideas quite absurd.
In my opinion, the situation is actually quite simple. We all assume – and have been able to observe this repeatedly in recent years – that all lines of business are becoming increasingly software-based business areas. This does not mean that physical processes are irrelevant, but that these physical processes are controlled and optimized by software. This is especially evident in logistics.
For example, micro-store concepts with hundreds of robots have taken over the small parts storage at pioneering companies. They are more reliable, super-efficient and can be integrated into the entire process chain.
Thus, all companies are entering new ground in conceptual and operational terms. Anyone who is able to implement new ideas by using software in the fastest and most efficient way will gain considerable competitive advantages.
Software is therefore not only a means to an end, but an asset in itself. It is a toolset that makes fundamental new processes possible. These processes are the breeding ground for new, partially disruptive, business models. I deliberately use the term “breeding ground”, because I do not think that the combination of ideas, culture, technology, software and completely new processes per se leads to new business models.
If you as an entrepreneur in this situation rely solely on standard software, you will continue to move in trodden paths. Because standard software, as the name suggests, is based on standards and best practices.
I think now it is also becoming clear why I advocate a “make and buy” strategy. Because not all processes have to be completely reinvented. These basic processes can be easily covered with standard software.
You will create real innovation in your business, however, by creating new concepts and there is no standard software for this – because innovation and new concepts simply are not standard.
In this context, it is of vital importance to be able to develop your own software. I am currently meeting many companies who recognize this need and are toying with the idea to assemble their own software teams.
This is a rather difficult task for companies that have no experience with software development.
I therefore advise almost all companies to avoid this approach and work with external, dedicated teams. I don‘t mean offshore teams because I haven‘t had the best experiences with that for the development of new innovations.
Rather, it is about creating exclusive teams with software service providers, which work soley for the company.
This allows a quick start into development. Such software service providers also bring a lot of basic know-how about software development to the table. At AOE, we support numerous Enterprise customers WITH such teams. Most of our clients can implement the first usable software component within a few short weeks.
Parallel to this, and I strongly recommend it, is to build your own teams. This is not for cost reasons, but for the simple reason that in the intermediate-term it will be one of the core competencies of a company to adapt software-based processes flexibly and / or to create new ones.
For, in a world of rapidly accelerating change, this flexibility and maneuverability is one of the basic prerequisites for successful economic action. And there, software if very high on the list of priorities.
Operating E-Commerce with a sustainable risk management system? Steffen Ritter & Steven Bailey explain how to do this in five steps (article in German).
RFPs are inefficient and a pain for everyone. We showcase what problems RFPs pose and why defining an MVP - a minimum viable product - is much more useful and efficient.