Several times now I’ve received the feedback that smart factory, industry 4.0 or manufacturing 4.0 projects have to be implemented from scratch and that to start such a factory it will be necessary for all concerned to learn the new system before you can start, as it will be completely different to everything people have seen before.
Sometimes software developers would like to just start from scratch all over again, and understandably so. The old system might be more than 30 years in its making now, got several partial makeovers to adapt to new technology and hundreds of extensions, adaptions, changes and bug fixes throughout its life. It all seems too complex already and to add more functionality for say a mass customisation extension with new user interfaces for order entry, automated quoting, machine data generation and machine control seems just to add more complexity again.
However, we sometimes underestimate the complex requirements of the existing software, and if we try to start from scratch, quite often after spending quite some time in rediscovering those requirements we find that there is not much we can simplify. After all, if all those that went before us working on that software were not completely ignorant, then they would have refactored it reasonably well with every major change, extension or upgrade.
For more than 35 years I’m now in the business of software in a technical environment and have seen many big bang project launches. Fortunately I was only actively participating in one of them and that had actually achieved its goals, albeit after working overtime, sleepless nights and a minor cost and time overrun.
Almost all others that I have experienced more as a bystander have either failed completely or were only partially completed, or they were late and with a massive cost overrun, and most of the time they were all of that: late, over budget and only partially complete. Usually those big projects take too long and are thus already technologically out-dated at the time of going life. Quite often their specifications were changed during the development process as well, to adapt the project to new technologies, products and markets. Sometimes the requirements were kept frozen to keep the costs in check, with the consequence that at the time of the launch part of the software was out-dated and not useful.
Big bang project launches are usually quite difficult too. People in long term employment quite often learn best on the job. You can try to educate them in advance as long as you want, it will all stay in the abstract. After training they will have to go back and do it all the old way anyway, so training in advance is difficult. And as hard as your software developer might have tried to find all the bugs, the last ones in a big new system are always found by the users. In addition to that users might want to use the system in a way that developers did not know or understand, thus creating more problems.
Think for example of the internet of things (IoT). Your industry might even have adopted one of the about a dozen existing “standards”. Which does not mean that this will be the overall standard that will emerge in about two years’ time. But if it makes sense to make a start now and if you have a project that you could have up and running in three months, then go for it! If the interface has to be changed two years down the track, then that does not mean that all the processing has to change.
It is good to have a vision. Looking at what you have and where you want to go quite often means it is not too hard to figure out where you want to make a start. If something changes, be it the market, your products, competition, or technology, then it is fairly easy to assess the new situation, figuring out where you stand and where you want to go and make the necessary adjustments for the next iteration.
That’s why I am a strong advocate of iterative development and agile programming. Even if it sometimes seems hard to find a way of doing it, thrust me, big bang implementations are even harder!