I recently revisited a blog I wrote several years back touting the capabilities and benefits of enabling engineering organizations to collaborate with the rest of the enterprise. I even coined a term for certain platforms that give companies the potential to go beyond just information sharing to a more interactive form of communication. Recent developments around IoT and medical device quality make this form of collaboration even more vital for optimized product development. Most companies still operate with a limited form of integration to their engineering organizations. To fully leverage today’s PLM and IoT solutions, it is vital that engineering is completely integrated into the enterprise. Over the next few weeks, we will be sharing content we present at Oracle’s upcoming MSCE event which will reemphasize this point. In the meantime, feel free to revisit my thoughts around EC Squared (blog article republished below) and how important it is to collaborate with your engineering organization.
It was pointed out in a blog by Oleg Shilovitsky that the term "Collaboration" is "massively used by CAD/PDM/PLM oriented companies". It definitely is a term we use often in describing our solutions. I have written several blogs previously on the topic including: Engineering-driven PLM versus Manufacturing-driven PLM "Clash of the Titans", Engineering Collaboration - "No Engineering Organization is an Island", and "The Deep Dive with Jacques Cousteau". We have also created a group on LinkedIn entitled "Engineering Collaboration for PLM" where we share relevant information about engineering collaboration in the context of product lifecycle management. We have created an "Engineering Collaboration Hub" which gathers all blog posts, videos, group links and presentations in one area to make it easier to find. But, unless you know what we mean by "engineering collaboration", it doesn't really matter how much information we provide on the topic. I like the Wikipedia definition of "Collaborate". It defines collaboration as "a recursive process where two or more people or organizations work together in an intersection of common goals." It also goes on to say the "structured methods of collaboration encourage introspection of behavior and communication and that they aim to increase the success of the teams as they engage in collaborative problem solving". I really wasn't expecting such a complete definition from Wikipedia, but I think that definitely captures the spirit of collaboration in the context of product development. On a micro level, PLM and PDM definitely facilitate communication between individuals. One common vault allows everyone to work from the same data set. Access Control Logic ensures the right people are seeing the information at the right time. Workflow automation routes information to the appropriate person and gives managers the ability to monitor process. PLM provides numerous tools which allow companies to collaborate internally. Where we differentiate between general collaboration and engineering collaboration is at a macro level. We are talking about between departments and between organizations. Our definition of engineering collaboration involves facilitating better processes and solutions around the sharing of information created by an engineering organization with the rest of the enterprise or with other companies that most likely would include customers and/or suppliers. This blog will further detail the specifics involved in facilitating this type of collaboration and what it entails.
Oleg's blog talks about IT establishing 3 baselines to enable collaboration, which includes support for: Online Access to everything, Unified Communication, and Multiple devices. Any PLM worth its salt should provide these things so we have the fundamental elements necessary for collaboration. Oleg's vision for collaboration is more ambitious than mine in that he identifies solutions that can unify all forms of communication including emails, phone communications and social channels. While I think these are useful solutions and having a framework to capture all this data might be useful, I tend to subscribe to a narrower definition of collaboration. Establishing a process and a toolset in which critical data will be conveyed is vital for successful engineering collaboration. Social media and email are great for ad hoc communication, but if anything important is shared through these channels, the onus is on the participants to capture that data in the PLM. True engineering collaboration enables the technical CAD data to be shared in a manner that is meaningful to other parts of a company or to external partners. PDM Professional from SOLIDWORKS vaults data and allows for automatic creation of viewables. It does have a user interface that is intuitive and it does have some workflow capabilities, so by my definition, it qualifies as an engineering collaboration solution both for engineers with each other and the rest of the enterprise. It doesn't offer full enterprise capabilities like AgilePLM from Oracle or PDMlink from PTC, so its collaborative capabilities are somewhat limited. It is a tool that any user can leverage, so I consider it more collaborative than Intralink from PTC which is a specialized PDM tool for Pro/Engineer CAD data. ProductPoint from PTC is more along the lines of PDM Professional. It has a familiar interface and integrates to SharePoint from Microsoft. It is clearly more collaborative than a CAD specific PDM but not as robust as a full PLM solution. Technically, it could be argued that all PDM and PLM tools are engineering collaboration tools; it just comes down to whether they allow collaboration with anyone outside of engineering. We really need another term to capture external collaboration...maybe we should call it Engineering Collaboration to the power of 2 or EC2 for short.
EC2 solutions allow engineers to publish information to the enterprise in a meaningful way. It doesn't do much good if your PLM vaults CAD data in a format that is only meaningful to engineers. Agile's EC Module allows engineers to keep data vaulted in a "sandbox" and then publish the data based on certain release states. When the data is published, the CAD data structure is transformed into a Bill of Material (BOM) Structure that is more meaningful to configuration management types and manufacturing resources. The information can then be viewed by a built in viewer that will allow users to interact with 3D data without having to master a CAD program. This functionality is a great example of EC2. PDMlink from PTC and Siemens' TeamCenter offer similar capabilities, so I think they also qualify as EC2 tools. The biggest concern with these two solutions is that their CAD DNA can potentially make them too technical to be effectively leveraged by the rest of the enterprise for CAD collaboration. On the other side of the coin, it can be argued that these types of solution offer engineers more robust CAD data management capability, which is necessary for traditional engineering collaboration.
Another type of tool that can qualify for EC2 status is an integration link between Engineering PDM and PLM. As I mentioned earlier, PDM Professional, Intralink and ProductPoint all offer traditional engineering collaboration capability. In fact, EDPM and ProductPoint even potentially qualify as EC2 solutions due to their user interfaces, but their lack of full enterprise PLM capabilities can potentially relegate them to department level solutions. Having integration between these types of tools and enterprise PLM can potentially offer the best of all worlds. Dedicated PDM systems can allow engineers to work in environments that are fully optimized for their maximum productivity. This approach also allows non-engineering types to use systems specifically designed for their productivity as well. No one is forced to compromise in order to accommodate others in the organization or outside the organization. Everyone uses the tool best suited for their role and integration ensures information is passed back and forth to keep everyone on the same page. Historically, this may have been a challenging technical problem to address; but, with the advent of web services and the adoption of this structure by most PLM and PDM solutions, it is a very viable way to address EC2.
The term "collaboration" is indeed vast in its use and meaning. Defining it further by adding "engineering" to the term does narrow things down, but still leaves room for interpretation. Many viewers, CAD data management tools, and PLM tools can claim to facilitate engineering collaboration. When you further define the term by limiting it to "tools that allow for collaboration between engineering and others", the list shortens significantly. Then, the decision becomes how best to facilitate the communication between groups. Hopefully after reading this blog, you have a better understanding of the terms and can adopt my newly coined term EC2. I think I might be able to collect royalties on it, so please use it liberally.
To further your learning of EC2, connect with us at Oracle's MSCE 2018. Schedule a 1:1 meeting and let's discuss the best way to integrate your Engineering and Design data into both on-premise and cloud-based PLM.
[Updated and reposted from 2015]
