It’s not just corporate IT managers who lose sleep over Industry 4.0. Members of companies’ top management often have to address this topic as well. No matter whether it’s because their digitalisation projects have been delayed, and they’re no longer keeping pace with the market, or because their projects’ budgets ran out long ago and long before bringing the expected benefits. Then their backlogs fill up with further digitalisation plans, for which they don’t have free capacity. Meanwhile, digitalisation success depends upon a well-configured IT strategy, in terms of not just the choice of products used, but also securing the appropriate resources (teams of professionals).
Thanks to our 20+ years of experience in digitalising manufacturing and logistics, we see corporate digitalisation projects from the perspectives of both central managers and local branches. And local manufacturing plants are truly where corporations’ added value is created. Their efficiency, flexibility and ability to deliver on time and at high quality have a fundamental influence on the whole corporation’s profits. During our many discussions with customers, we’ve noted several commonalities that underlie the often difficult and awkward births of global projects. We’d like to share our experience and opinions with you in this mini-series that we’ve prepared for you that’s dedicated to strategic topics from the domain of corporate IT managers. The first of our topics is The cornerstone of every digital factory. For us, that’s none other than ERP.
In our times of automation, robots and the IoT, why such a boring topic as ERP? You can’t build a digital factory without stable cornerstones – both physical stones and software building blocks. And ERP is one of these cornerstones. Like it or not, it is – in our opinion – still the backbone of the whole integrated solution, the one upon which the remaining production and logistics systems rely. You see, many companies yearn for a beautiful, standardised IT solution that’s the same worldwide and that unifies all of their processes. In short, a lovely manufacturing company paradise. Their thought here is that the costs and risks connected with the administration of a number of heterogeneous systems are too high; they demand separate administration and mutual integration, and that brings nothing but trouble. And these companies surely have the right idea. So how can they make it a reality?
Logically, most companies begin their deployment of a unified ERP solution (this is usually SAP) with a pilot branch, one that deals with the majority of the same processes that the company does overall, and this subsidiary is usually then presented as a model for others. At this branch, a team of professionals delivers a pilot project, with the goal of creating a corporate template. However, the approaches to implementation vary from case to case.
A variety of approaches to implementing ERP
The first possible approach to a corporate ERP solution is to create a system with very specialised functions and lean processes on the level of manufacturing or warehouse management. That means for example one with transaction screens for mobile devices or with touch screens for production or quality announcements, with VNA integration, etc. The key stumbling block here is that no entirely standard ERP system supports these transactions in a truly lean form. So this is the moment where a consultant comes in, either internal or external, and it’s often a very senior one (in plain English: one that can write program code) and creates transactions tailored for the pilot, i.e. model plant. Then comes the moment when the corporation begins speaking confidently of a completely standard, unmodified SAP template.
This is followed by expansion to the other plants, where the team suddenly discovers that every plant really does need something slightly different after all. The real-world reasons for this are many, for example cultural (Germany vs. the USA), topological (legacy issues in old halls), differing manufacturing and warehousing technologies, product differences large and small, differing quality levels from local suppliers, differing traceability requirements and so on. So once again a consultant comes in – if the company is lucky, it’s the same one – and modifies the processes. Quite often they don’t just configure; they code. I probably don’t need to explain how tattered the template looks after deployment at the seventh location. We know of corporations where they’re already on the third launch of their corporate template over the last ten years.
Some companies, meanwhile, choose a fixed corporate template from whose processes not an inch of deviance to the left or to the right is allowed. Once again, I probably don’t need to explain how well these are received by the plants, especially the one with large production volumes. During their existence, they’ve each nursed a local SAP instance in which they have process variants that provide the specific functions for their processes, and now suddenly here comes headquarters with its new “decree”…
The third option is the minimalist one. The head office prepares a template providing for internal logistics in SAP without the WM (Warehouse Management) module and without handling units. However, this variant can’t address what that plants really need – efficiently managed logistics and production – and meanwhile it just kicks the same dilemma down one level, into their WMS and MES systems. Here they then have to address the very same requirements for standardisation, robustness and flexibility.
The fourth approach is to use further integrated modules from the software supplier, for example the EWM module from SAP – but that, along with SAP S/4HANA, is a subject for a separate article.
So what, then, is the right solution? In my opinion, standardisation really is the right idea, and a standard corporate template is the only right direction. But the question is, how do you “steer” it?
The first step towards success – and it’s a fundamental one – is to realise that any kind of modification to ERP is actually software development. And that demands a professional approach. What’s more, when you want to standardise, logically that should probably mean standard software. There’s a difference between spending fifty dev-days on developing a few warehouse scanner transactions, and spending hundreds to thousands of such days on developing a standardised add-on for lean stock management in automotive. You see, on the warehouse or workroom level, no one single ingenious standard transaction template exists. Even inside of a single corporation, reality is often about considerable process diversity. A global seat manufacturer can serve as an example here – processes at the materials warehouse often differ significantly from the processes at the plants that manufacture seat structures and trims and perform JIS seat assembly. Even within a single seat manufacturing plant, they’ll work differently with “cow” than they do with rolls of textiles.
The ideal route here is a configurable, or better yet composable solution, where the corporate process template can be flexibly recomposed in a way that’s tailored to the local specifics, while still meeting the head office’s requirements for the given transaction. One of our customers has aptly called this kind of template composed of functional modules die Bausteine – the building block. The local versions of transactions are then produced error-free and with no programming needed, i.e. without needing detailed specifications, coding and lengthy testing. It also has one more important impact: it fundamentally reduces the time from the GAP analysis to the first prototype. Meanwhile the corporate team has everything under control and always knows what it can expect from a localised transaction.
Another important guideline is specialisation, for which there’s no better example than automotive with its supply-chain structure. We’ve had to introduce specialisation into our teams as well; for example in the Warehouse Management System area, we have specialists for such processes as those for optimising warehouse routes, for returnable packaging and for production halls and aftermarket distribution centres. Yet despite all of this, in mid-sized automotive enterprises, teams of 4–6 internal consultants quite typically deploy the entire ERP system. With every new customer, we keep learning new things.
Our final question might be: To what extent can professional software development (even modification is development) and specialisation and the preparation of a configurable solution be handled using internal resources only? But with my thoughts on that topic, I’d be jumping the gun, or rather, I’d be divulging the contents of the next part of this mini-series. So next time I’ll be presenting you with my thoughts on the subject of Do It Yourself, that is: handling critical business systems using internal resources only.
Author’s note: nothing of the above should be taken as dogma; it’s all about compromise and seeking a balance. I’ll be glad if this article ends up sparking a discussion. Write me at firstname.lastname@example.org.