The Anatomy of a PLM 360 Tenant
I recently had the privilege of attending two Autodesk PLM 360 classes, and I would like to share some of what I learned with you. I will be writing and reviewing PLM and to start off, let’s just define the Anatomy of a PLM.
A PLM 360 tenant contains one or more workspaces working either individually or in concert to mimic business processes. Out of the box, PLM 360 includes a number of predefined workspaces, and they are organized into categories such as Project Management, Quality, Sales & Marketing, and so on. The categories, which can be completely reconfigured to suit your needs, correspond to the Main Menu items as shown below. The cascading submenus within each category you define take you to the workspaces themselves. The image below shows a simple “Root Cause” workspace I created that contains a single record.
Workspaces – of which there are six basic types – consist of fields you define to hold whatever data you want them to, and tabs of various types to either receive input, control workflows, add attachments, or display content in one form or another.
If you have ever built Access database tables and forms, the process of adding fields to the Item Details tab of workspace will come very naturally to you. You name the field, define the type of data it will host (text, numeric, date, etc.) and then select the control type that will be used to enter or display the data. A rich selection of controls is available for this purpose. If you have done any web development, you will be surprised and pleased to discover that there are even provisions for rendering complex HTML structures like iframes in PLM 360 fields. An example of this is the embedding of Google Maps PLM 360 workspaces.
Once defined, the fields themselves can be grouped into Sections, which can be visible or not to users based on the permissions you set on the workspace.
Each workspace can host as many as 15 possible tabs (see below), each one having a different purpose. For example, Item Tabs display field data associated with individual records, and Grid Tabs have Excel spreadsheet-like capabilities. Each of the tabs can also be renamed so that its legend aligns with terminology used in the business process being modeled. Currently, workspaces support only one of each tab type, but I have a hunch this limitation will be addressed as PLM 360 matures.
PLM 360 also sports a Workflow Editor, which allows you to define in minute detail how work happens in your organization. It allows you to graphically specify milestones, transitions, and branching operations based on criteria you define. These can be quite simple, or, through the use of Java scripts, be as complex as your processes require. PLM 360 comes with quite an assortment of prebuilt scripts, and these can be copied and modified by technically savvy administrative types to create new Condition, Validation, Action, and even Library scripts without having to be a professional programmer.
Stay tuned and I will share more soon!
David Wyer has over 25 years of CAD experience, eight of which focused on data management and extending the functionality of Autodesk software. David is a member of the Autodesk Developers Network, joining Synergis in 2011. Prior to this, he was a data management applications engineer, responsible for data management and CAD needs analysis and implementation and support relating to these products.