Traditionally shipyards who purchase an existing design (usually from northern Europe or Asia) have often chosen to independently produce a detailed and/or production design using whatever software they already use. While they leverage some of the information contained in the design, direct use of the basic design and the software it was created in was few and far between.
There have been a number of reasons cited for this lack of reuse in the past. Many of these reasons are still as valid today as they were then. The primary reasons are related to liability issues, cost, and unfamiliarity with other toolsets.
Liability/Responsibility
A primary concern/risk of reusing data provided by another organization surrounds the liability and responsibility for errors in that information. The complexity of design information for (and the impact of errors on) a shipbuilding or offshore construction project ensures that the organization providing basic designs will accept very limited, if any, liability for downstream impacts of errors or omissions in the data.
Engineering departments that are correctly held to account for the quality/reliability of the information being generated and fed to the rest of the shipyard have been reticent about accepting a design they themselves didn’t create (or have been absolved of responsibility for at least). I have heard many engineering managers explicitly state that they can’t trust and won’t rely on information they were not responsible for creating.
Unfamiliarity
As mentioned in one of my previous blog posts specific regions and the users in them seem to standardize on a single platform of technology. Finding enough highly skilled people who can use (much less implement) a new technology in another market is a challenge. A few recent projects where the design was delivered in another software package AND a decision was made to use that software for production have met with poor results. The costs in these situations can be greater than performing the detail design independently in ShipConstructor (the jury is still out on whether that’s due to the openness of ShipConstructor platform, or if it would be true of any software the yard was familiar with).
Even if it was possible to find and maintain a skilled engineering workforce in more than one tool the cost of doing so would be prohibitive. And the reality of our industry is that there are at least 5-6 major vendors of software capable of basic and production design. The number is smaller when looking at particular markets and segments (OSV’s for example are largely designed in ShipConstructor, AVEVA Marine or Nupas Cadmatic) but never drops below 2 or 3 solutions.
Empowered Engineering
These days engineering solutions are not (or should not be) confined to engineering. Successful organizations leverage design data in engineering, purchasing, planning, production, sales, marketing, feedback loops between departments and more. This requires integration (manual or automated) into a wide array of other process, people and tools. Introducing a second or third toolset into an organization either doubles the complexity/effort required or reduces the intelligence and benefits of the integration to a neutral set of formats and processes that can be supported by all.
Winds of Change
Despite all of the reasons to not leverage design and engineering information provided by a 3rd party in another software solution, we are more often seeing a willingness to do so. As I mentioned earlier we have even seen a few examples where ShipConstructor clients chose to directly use designs delivered in other software and implement that software, even if only on that single project. Even though the results on these projects weren’t what they were hoping, the clients made the attempt.
Given the many historic reasons to not do so, and the broad gulf between the costs of engineering and the material and labour costs in production these seemingly isolated incidents are more significant than they appear.
When looking at the shipbuilding industry, and its current depressed state it’s no surprise that both designers, and other software vendors, are looking towards the more successful market segments and aggressively trying to gain some traction there. We’re likely seeing this trend more so because our traditional market segments (workboats, Navy vessels, and offshore – OSV’s and jackups) are still strong. It also doesn’t hurt that generally speaking SSI’s clients are generally a healthy bunch that attracts attention from competitors.
Additionally the shipbuilding industry is a very difficult environment in which to survive, much less succeed, and it is becoming tougher every day. Organizations are looking to more and more creative ways to improve the bottom line and reuse of data looks like a no-brainer.
Last but not least we are seeing a trend towards large multi-national shipbuilding organizations acquiring even smaller traditional workboat builders in an attempt to reach economies of scale and diversification to ride out a tough patch in our industry. These organizations are far more likely to drive the reuse of data across the organization, even going so far as to standardize on the same technology. This can be a very successful approach in today’s market, but some of these organizations are either well aware of the challenges that can involve or finding out rather quickly.
Conclusions
There isn’t a single answer to this challenge that fits every project or organization. The key factors to consider are availability and maintainability of skilled people (it all comes back to people), the complexity of the organizational infrastructure and processes built up around the current tooling, and the ability to limit the exposure to and impact of risk due to errors or omissions in any existing data that is to be reused. In the end someone needs to take responsibility to go one way or the other based on these and other factors particular to the project or shipyard.