Manufacturing companies are full of very smart people: engineers, technicians, skilled operators, maintenance people and so on. So, sometimes DIY (Do It Yourself) is the way to go to solve many problems in the company.

This is not different when it comes to analytics systems for the production (sometimes called MES systems) and this is a valid approach. Software development is hard, but we must say that some companies are successfully doing it. Here we try to enumerate some of the mistakes that are normally made by manufacturing companies when trying to develop their own systems.

This happens in house renovations as well: we start wanting to replace the floor tiles, which would take us one month, but end up breaking walls. Since we are breaking the walls, we could as well remake the bathroom, and so on.

Normally a project for production metrics at a company starts with: “let’s just add some sensors and save them on an SQL database, and we already know production, uptime, and speed” ( and that is a nice way to start ). But then new demands come: “how do we know the production by a customer?”, “how do we know why the machine has stopped?”. “What was the production by shift?”. The list is immense and every new question that the system has to answer, add complexity in an exponential way. In short: the complexity of such systems is normally underrated.

How to avoid this: start with the questions. Make a list of all questions that your system must answer and divide them into two: which are the must-haves and which are the nice-to-haves. This should happen involving operators, shift leaders, plant managers, and production directors.

Modern software development has changed a lot in the last 10-20 years. In the ’90s and at the beginning of the ’00s smart engineers would lock themselves in a room only to leave 12 months later with a product that end users would have to swallow (normally without water). In most manufacturing companies, systems are designed by a smart technician, that understands SCADA systems and databases,but without much understanding of the user.

The problem is that users have changed too in the last 20 years. Even the humblest machine operator in most countries carries a smartphone in his pocket and has access to well-designed applications. That makes them hate the software they have to work with at the factory even more. They are currently “demanding” software that has been designed for them, otherwise, they will refuse to use it.

How to avoid this: make user interviews and/or bring a UX designer onboard early on in the development process.

Another frequent mistake that non-software companies make when developing systems is to go from planning directly to execution. The end result is normally a system that lacks engagement from the user. This is very much related to the point above, however, it is so important that it deserves its own item.

The software development process is an iterative one. You normally do not know what the end product will look like. And this is mostly because most people (users) do not know what they want/need until they see it. The concept of MVP (minimum viable product/prototype) was coined by Marty Cagan and later made popular by Eric Ries in his best-seller The Lean Startup. The theory behind it is: make short deliveries and test them with the user as often as possible. Or: “if you are not embarrassed with your MVP, you’ve waited to o long to ship it”. This process of iteration will bring a lot of learning to the development team.

How to avoid it: orient the development team to develop Lo-Fi solutions and testing them with users before developing the final version. Sometimes this can even be done without a single line of code.

When teams develop an IT system for the first time, they tend to think of screens and interfaces. Which graph to show, what inputs to ask from the user and so on. However, this is only the tip of the iceberg. There is a lot of things that must happen in the background for a piece of software to run in a reliable fashion: security, automatic backup in different levels, data collection pipeline, user registration, parameterization of production lines characteristics and the list goes on. These are things that are normally invisible to the user but can consume up to 70-80% of the development efforts.

Besides, without an MVP mindset, inexperienced development teams tend to accept huge “specs sheets”, where all possible stakeholders add their wishes.

This is the most frequent single reason why companies fail when trying to implement a system: the project becomes too complex, takes 3x longer than expected and costs 5x the budget, leading to huge frustration. In the end, it is better to abandon the project than moving on.

How to avoid: align expectations and start small. Bring a team of experienced developers to support you with the back end and infrastructure.

Just like machines, software needs to be maintained in order to keep running in the long term. This is one of the biggest challenges of software development in companies where software development is not their core business. Usually, there is either a small team working on it part-time or even a single person, the project hero. When changes or maintenance are needed, this is the team/person that will have to do it and the bad news is: changes are more frequent than we would like.

With the possibility of working from anywhere in the world, keeping good software developers nowadays is more difficult than ever, it doesn’t matter if your company is in southern Germany or in Timbuktu. And guess what sometimes happens: when the system is about to get ready, your developer receives a job offer to work at Google. He will promise that he will comment on the code, train his successor (if you are able to find one on time), but in the end, what happens is that the project is delayed in at least 6 months every time your champion leaves. That is quite common with companies that use Excel and the “macros-guy” leaves.

How to avoid: creating an actual software development department with more people involved and with autonomy is the only way to avoid this trap. Sorry, I don’t have better news here. Working as a team, they will all somehow understand a bit of everyone’s work and will be able to cover someone’s job temporarily, if necessary. This is a possibility for bigger companies, but much harder for small and medium-sized companies.

Yes, although there are many sorts of frameworks, libraries, and platforms that have made software development much easier than it used to be, software development is not yet what one could call a piece of cake.

There are certainly more mistakes to avoid and software development will always be a journey full of surprises, but avoiding these traps will already give you a head start against all other companies that have tried and failed.