23 June 2020
Standardisation is high on the agenda for many companies. Ask a group of people whether they have a standard within their organisation and you’ll often get surprising results. Some hands are raised, others not. Hardly surprising really, because a standard is a broad concept. We regularly hear from project managers and engineers that “The only good standard is the one on a flagpole,” or “Our most recent projects are our standard.” Sound familiar? When we talk about Industrial Automation, we’re quick to think of machine builders, system integrators and end customers. One of the challenges seen everywhere in this market is project pressure. In busy times it often prevails over achieving a good standard. That’s logical, given the enormous time pressure on projects. The project’s data is often incomplete at its start, but good quality is still expected by the deadline.
A standard is often associated with something that’s rigid, cumbersome and bureaucratic. The word ‘standard’ or ‘standardisation’ has many definitions. For the industry, we could define a standard as ‘recognised agreements on products, specifications and documents’. The standard we have in mind is a means of creating uniformity. Examples are uniform descriptions, product definitions, good tag coding, typicals per discipline (a piece of project documentation with variables), product data, construction of software and/or hardware, and last but not least the process around it. Within the industry we regularly encounter terms like ‘company standard, project standard and customer standard’. Standardisation is always a good idea, but the degree of investment in a standard varies. How much time and energy standardisation takes depends, for example, on the number of objects and the structure of the standard.
A good standard has plenty of benefits. Among them are:
There’s a serious shortage of technical specialists, and we’re experiencing a greying population in the technical world. Knowledge resides in the minds of experienced employees. It’s very important to safeguard this knowledge in a standard that’s available to other employees. That also makes it possible to onboard new colleagues faster and to call in extra capacity.
Names, typicals, documents, reports and other important matters are coordinated and recorded in advance. At the start of a project, you know the end result in advance, irrespective of which engineer worked on it. If it comes out wrong once, it comes out wrong everywhere. If you record it correctly up front, that guarantees good quality and unambiguous information and project documentation. Uniformity and recognisability of documents and names often results in happy faces.
A good standard saves time. It’s much easier to define what information is needed within a discipline at the start of a project. The engineer is busy collecting the data and can focus further on specials. Because there are fewer uncertainties, it’s also easier to plan. The same number of people do more work. And the distribution of tasks can be done more efficiently.
Using a standard requires less attention from the project engineer. This applies particularly to objects that occur regularly and are regarded as ‘a piece of cake’. After all, once defined well, always the same. In his projects this gives the engineer more time to think about the technical solution for its more complex items. So he can work with these issues much earlier in his project, which ultimately results in a better thought-out design. Does a standard then only have advantages? The word ‘standardisation’ often suggests a less positive energy. That’s understandable when you consider that flexibility and choice are being sacrificed. Nevertheless, a standard will have to move with the times, thus producing a dynamic standard or the creation of uniformity. A standard is a good goal, but remember that there are many team members who influence a standard. That’s precisely where the challenge lies. After all, it’s the team that determines the success.
Many choices must be made before you can arrive at a good standard. This often forces different teams to talk to each other, leading to healthy discussions that have not been held before. Standardisation requires coordination across the various disciplines. A standard is not a law, but a means of achieving uniformity. To a limited extent it lets you remain flexible. It’s important to start standardising before anchoring or automating the standard and the process. Creating a good (multidisciplinary) standard takes much more time than automating it. We’ll tell you more about this in one of our subsequent blogs. Are you thinking of starting a standardisation process for one or more disciplines? Or would you like to go through the process with an experienced consultant? Then please contact us.
23 June 2020
Excellent product data management provides great benefits. Especially in electrical engineering, where...Read more