00:35 What are the challenges that you have seen?
02:28 Which are the important features of a software architecture?
05:09 How obvious are these challenges?
09:11 In a supply chain piece of software, what are the key core assumptions that are being made? Which ones are not really working?
12:18 Which are the key differences between a single tenant piece of software and a multi-tenant one?
15:33 Would you say that the marketplace is moving towards that SaaS model? Why is it better?
17:55 What were the core assumptions that you made at Lokad?
21:33 What is our main conclusion for today’s episode?
Lean Supply Chain Management (Lean SCM) starts with a lean applicative landscape to support the supply chain. However, ‘lean’ in software is primarily a matter of architectural choices. Those choices define the class of problems where the chosen software design is a good fit, and where it isn’t. Many supply chain problems stem from broken-by-design situations where core design choices conflict with real-world requirements.
When starting a company, there are a number of strategic decisions that have a very real impact on future operations. Physical decisions, such as location and vertical, have an obvious impact; however the very design of a piece of software is something that is often poorly understood and has an impact that is often more far-reaching. In this episode of LokadTV, we try to expand on how these software choices can end up ‘pigeonholing’ a company and what are some of the pitfalls to look out for.
Most modern supply chains rely on a complex web of software, from machinery such as conveyor belts and barcode scanners, to ERPs, MRPs, etc. Usually, the problems don’t lie in an obivous issue like a bug, but more in the applicative landscape, which is to say more pervasive, design-related problems. For example, software is slow or simply not intuitive, it’s hard to modify the systems or even to update them.
There is also the immense complexity of real time systems. Most supply chain systems are “real time”, i.e. picking one unit off a shelf decrements the stock level immediately, which makes a lot of sense. Unfortunately, as soon as software is designed for real-time, any sophisticated calculation (such as a forecast) will be difficult to implement. Why? Because the software is designed for small, swift and simple operations. Anything else will slow it down too much. Often, companies end up with a growing backlog of non-real time elements that clog the system.
In addition, when designing software you need to take into account the time scale you’re operating with. Whether it needs sub millisecond response times, or a response time that takes place within a few seconds or managing decisions that can take years (locating a new factory for example), each requires a different type of software.
To wrap things up, we discuss the major differences between single and multi-tenant software. There’s the all important question of customizing, which creates operational problems for the software vendor as there are multiple variants of their programmes running, which in turn creates huge versioning issues. This is a notable challenge for Oracle for example. We can observe that the market is moving towards multi-tenant, SaaS, systems with one codebase for everyone, such as Microsoft is doing.