In my previous blog post Change Management with SSI 1/3 I discussed the mechanism to have all changes a ShipConstructor user makes to the project associated to the specific task they are implementing (ex. ECO 1234). This traceability of the changes can be used for reporting as you would expect; however, it can also be used to generate several content packages for different stakeholders. Think of it as each stakeholder getting a customized set of only the information they need and in a way that they can consume. This can be a content package which includes BOM’s, PDF’s of production drawings, nest tapes, pipe bending information, profile cutting machine data, a visual model containing just the changed items and many more.
In this blog post I will expand the change management scope by discussing the scenario with multiple changes by multiple users happening at the same time which is the typical scenario. In this scenario you will need to communicate with external stakeholders as in the previous post; however, there will also need to be a way to communicate your changes with the other disciplines of the engineering team in a real-time true concurrent way.
Users Working Concurrently
Allowing concurrent work from all disciplines (Hull & Structure, Pipe, HVAC, Equipment, Electrical, Welding, planning, etc.) on the same product data model is a key feature of ShipConstructor.
Management of ShipConstructor tasks and the associated changes also supports true concurrent engineering. Each user, no matter what discipline, will be presented with only the tasks assigned to them. Once they select their active task, any changes in any discipline are associated to that task. From a ShipConstructor end-user perspective they will use ShipConstructor as they always have with no additional actions required to track changes. This means they get all the concurrent engineering benefits that ShipConstructor has always provided.
Show Changes of Any Task
With ShipConstructor Task Show Changes, each user will have the ability to discover the tasks which may affect them (preventative) as well as identify any of the tasks that have the potential for impacting them. This can be a change to a particular assembly structure which changes manufacturing deliverables, a change to the model which will now require a penetration to be created or even change which the user should not have done.
One of the challenges when working in a concurrent environment is the potential of multiple changes that will conflict with one another. This can happen often for outfitting when the structure teams make certain changes to the model that now occupies space originally planned for piping. Since they are both working in the same product data model you are able to see these changes in real-time as long as you know where to look.
The ShipConstructor Task Show Changes gives a user a summarized list of the changes made from their colleagues when implementing another task. It categorizes the list for easy consumption but also allows the user several methods to filter the information to extract the information they will need (ex. Filter by unit)
Referencing other Task changes in ShipConstructor
Structure Modeler making changes to a deck and referencing only the items changed in another Task.
The ShipConstructor Task Management and Show Changes features are useful but in many cases users want a visual representation of their colleagues’ changes and want to be able to interact with only the changes. In particular, they will want to easily pick a task and get a representation in their current model so they can orbit, zoom and see how the changes will affect them.
There are several strategies to do this. If you are automating the generation of the change packages as explained in the previous post, you will be able to use the ShipConstructor Coordination Model feature to load the changed Navisworks model. This has the benefit of including many changes without affecting performance. You can easily load a ShipConstructor Task or multiple tasks encompassing 10, 000 part changes without any issue. You could also leverage the information in the change packages of other tasks to do interference or clash detection.
Communicating Concurrent Individual Changes
As discussed in my previous blog post there is the requirement to present the change to each stakeholder in a format and context that they can consume. The source information for each stakeholder is the same; however, how we represent this information to each of them will be unique. This will allow each stakeholder to get a custom content package with only the information they care about to make quick and informed decisions with the most up-to-date information.
All tailored content packages uses the exact same source of information which ensures all stakeholder, including systems, will have synchronized information.
The generation of the tailored content package is all generated by SSI’s EnterprisePlatform and can be set up globally for the project or your enterprise. For example, you can specify what information is contained in the weight engineers’ content package, which will be different from the information in the quality control content package, which is also different than is in shop floor content package. There is also the case where you may be storing all information in an Information Platform such as PLM/ERP/MRP/etc. and have the platform be used as your delivery mechanism to the rest of your organization. This will be discussed more in my next blog post.
Communicating All Changes of All Open Tasks
In some cases your end stakeholders will not want to know the changes of a specific task but rather want an aggregated view of all related information from all active or recently completed tasks. This can be achieved using the same method as the individual tasks but instead of creating a content package for each ShipConstructor Task we will create one content package that contains all changes from multiple tasks.
There is no restriction of the content which can be generated from multiple tasks. The same content and formats are available. This includes a 3D interactive visual representation of only the changes in selected tasks which allows for a very efficient method of communicating data. For example navigate the below model and experience how fast it is for you to get an idea what changed without being familiar with the project.
Above is a 3D Visualization included in a content package which includes multiple changes (ECO’s).
A good change management strategy will support the distribution of information to the diverse set of stakeholders in a timely manner and in a context that can be consumed easily. Not all stakeholders will require information at the same time and do not need to be spammed with multiple individual changes.
With concurrent changes happing to the model you will have other engineering stakeholders who want information of their colleague’s changes that may affect them. They will want this to be able to happen in real time as well as provide the context of the change in the model they are currently using.
Even with concurrent changes there will be certain stakeholders who want to see each collection of changes associated to a specific task (ex. ECO) separately. This can be for class compliance, client records if a change is being charged back, or to aid quality control. On the other hand you will also have other stakeholders who just want to see all the changes aggregated together. An effective change management strategy will require to support all these type of stakeholders and be adaptable to support many other stakeholder requirements.
In my next blog post I will be discussing a more streamlined method to distribute the information associated to a specific task to your entire organization. This is using an Information Platform such as a PLM, ERP, PDM, ePDM, etc. These platforms act as a central information repository which can more efficiently distribute information.