In my previous blog posts Change Management with SSI (1 of 3), Change Management with SSI (2 of 3), I illustrated how you would be able to leverage SSI’s products to manage change in an engineering context as well as how to provide consumable content to the diverse group of shipyard stakeholders. However, the ability to generate content rich information custom tailored for each stakeholder in packages still leaves room for improvement. Most shipyards are evaluating their information systems, tools and environment in their quest for a business transformation. This search is leading them towards the capability to be able to leverage all their information from a centralized information platform. This platform will consume, store and configuration manage information from several different sources including products such as ShipConstructor as well as distribute this information to the many diverse stakeholders in a shipyard. A common information platform that is being adopted and implemented in shipbuilding is a PLM system.
The integration of an information platform with ShipConstructor is a key requirement for an optimal and streamlined change management process. This includes synchronizing the tasks created in the information platform with ShipConstructor tasks, associating the changed items including deliverables to a specific task and disseminating the information throughout the enterprise.
How to Stop Worrying About Shipbuilding Change – WebinarWatch now
Creation of ShipConstructor Tasks
Most information platforms have the ability to manage all the activities required for shipbuilding. These activities encompass much more than just engineering and therefore are managed holistically in the information platform.
The first connection point between ShipConstructor and your centralized platform is the ability to synchronize the tasks. ShipConstructor will simply represent the tasks managed in your information platform which is the source of the information. This will allow ShipConstructor users to have a familiar user experience which is native to ShipConstructor. ShipConstructor users will have no idea if the tasks are created in ShipConstructor or linked to a PLM system nor should they care where the task was created.
Using the SSI’s EnterprisePlatform you can create, delete, close and assign users to tasks via a REST API. For those not familiar with what a REST API is, you can think of it as a modern way to initiate actions or transfer data across applications. It can be as simple as calling a URL/webpage. Leveraging the REST API, the information platform will be able to manage all aspects of ShipConstructor Tasks without even having ShipConstructor installed.
Creation of Sub-Tasks Not Managed in Information Platform
Highlighted in blue are subtasks created in ShipConstructor which help breakdown and distribute tasks across the teams which do not need to be managed in Information Platform.
In certain cases, the task managed in the information platform is too large for a specific user or team. Therefore, there is a requirement for the discipline manager to be able to break down the task synchronized with the platform into multiple sub-tasks. The creation of sub-tasks does not affect the parent task and all changes in all sub-tasks will automatically get rolled up to the parent task.
It does not matter if the ShipConstructor tasks are created via an external system using the EnterprisePlatform REST API or if they were created in ShipConstructor Task Management window; the ShipConstructor user will interact with the tasks the exact same way.
They will simply be prompted with a list of tasks that are only assigned to them prior to making any changes to the ShipConstructor project. Once they select their active task, they can continue using ShipConstructor as usual.
Eventually there will be a need to publish the information of the ShipConstructor Task to the information platform. This can be automated so that it is updated daily if there is a requirement to pass Work In Progress (WIP) to the platform. Alternatively, the information can be published when the task is complete. You will also be able to pass different representations of the changed information to the platform depending on your requirements. For example, your WIP publish may only require BOM information while your baseline will require BOM, PDF’s of deliverable drawings, STEP files, CNC files, Native DWG, images such as PNG, and a representation of each part, etc.
A common type of output I suggest including (especially for ECO’s) is a 3D interactive visual representation of just the items that have changed. This is in order to better communicate the change to other stakeholders. If you would like to learn about this, I have showed it in previous posts. It is a great way to quickly see and interact with the items which have changed.
Depending on your company’s workflows there are several ways a ShipConstructor task can be closed (completed). The strategy you will choose will depend on how you manage your tasks. If your team member who closes engineering tasks works in ShipConstructor frequently you may choose to use the ShipConstructor Task management window to close all the tasks and sub-tasks.
However, if the team member who is responsible for closing the engineering task spends more of their time in the information platform then they should close the task in the information platform which will send the request behind the scenes to ShipConstructor to close the task. This can initiate the generation of information which will be consumed, stored and configuration managed in the information platform.
Want to Learn More
I have only scratched the surface with Change Management. If you want to learn more about how ShipConstructor integrates with your enterprise systems, you can navigate to ARCOS Innovations where they have real experience implementing a fully integrated system servicing your entire organization.
Disclaimer: I am a co-founder of ARCOS Innovations Inc.:).
The complexity of shipbuilding makes change management one of the most complicated activities we face in shipbuilding. Understanding what has changed and progressing the correct information to all the diverse stakeholders in a format they can consume is the number one problem we all need to solve with change management.
Your CAD tool will have features to aid in the generation of various content packages containing the required information of the change which can be stored in a corporate folder such as “X Drive.” However, this does not ensure that this information will be effectively communicated to the people who need to know the change occurred.
Therefore, many organizations are implementing an Information Platform which will consume, store, configuration manage, distribute and synchronize all your systems and stakeholders who require this information. It will also contain user transparent processes/workflows which will deliver the information to the right stakeholder only when they need to know. This will ensure all stakeholders know of the change, they can consume it to make a decision and will not be inundated with spamJ.
Integration with the CAD platform and the Information Platform is required to be a first-class citizen feature which will mean all the correlating, generation and delivery of information will be invisible to all end users.