To help support this announcement, CIMdata recently conducted research on the need for 3D remote visualization technology to support mobile product lifecycle management (PLM). This survey was intended for product development or manufacturing personnel that create or access computer-aided design (CAD) technical data or IT staff that support users who create or access 3D content. CIMdata was attempting to validate several use cases for remote access to 3D data, referred to in the survey as “remote visualization,” and wanted to understand if the respondents’ companies were experiencing issues related to these use cases and the importance of each. The use cases described include:

• CAD Education – To ensure optimal usage of complex 3D technology many companies have an internal training environment consisting of a physical or virtual training room, with workstations with software. Maintenance of a training environment can be time consuming. Workstations are typically reloaded or reimaged to ensure that they are properly configured and will work correctly during the training.
• Collaborative Design – Collaborative design can occur both synchronously and asynchronously. Collaboration environments can be physical or virtual. In the physical realm, creating a collaborative space can be as simple as making more physical space by consolidating the number of computers used by each team member. In the virtual or online realm, access to data and applications is the key requirement. Providing the appropriate collaboration environment enables teams to make better decisions faster which improves business performance.
• Disaster Recovery – Business continuity or disaster recovery planning is an important aspect of business strategy. Disasters can range from a major power outage due to a storm through the destruction of a facility. An example of a major disaster would be companies that operated within the evacuation zone around the Fukushima nuclear plant. Many companies were not able to get access to their facilities after the disaster. The following questions are oriented around your need to access 3D data if your company’s access to data was interrupted by a disaster.
• Hardware and Software Upgrades – As applications gain features and data sets grow larger more computational power is required. Companies must often invest in new hardware to obtain the value of new capabilities. Deploying new hardware as a unit across the enterprise is expensive and may replace many workstations unnecessarily. Deploying new hardware only where it is needed adds complexity to the environment and infrastructure. Distribution of applications and software fixes to hundreds or thousands of geographically dispersed workstations can be time consuming and costly.
• Mobile access to data – access to data contains two key characteristics. First, the data is accessed wirelessly either over Wi-Fi or a cellular network (3G, 4G, etc.). Second, the device being used to access the 3D data is small and lower performance when compared with the typical 3D desktop computer. Example devices include laptops, netbook computers, tablets, and smartphones.

Within the context of this survey, mobile PLM means accessing 3D data away from a user’s desktop solution, or in a remote office away from the data center.

Overall, CIMdata believes that the survey attracted the right type of respondents to help us understand the relative value of the five use cases. Over 50% of the respondents come from companies larger than $1B, which represent an appropriate target market for advanced hardware and software technologies.

A majority of the respondents reported that they are active users of 3D in their job role, with 63% acting as authors, reviewers, or viewers of 3D data. Nearly 90% of the respondents came from North America and Europe. Ideally, the geographic spread of respondents would be broader, but based on CIMdata’s annual global PLM market analysis these geographies have historically invested more in PLM-enabling technologies, making this a valuable set of survey respondents.

The collaborative design use case had by far the highest rank. More than half of the respondents rated it number one or two. It had more than twice the number of number one votes than the second place use case. The remaining four use cases were within about 10% of each other in importance.

For more information on the results of the survey, look for the detailed paper on www.cimdata.com. You can find more on the Citrix announcement at http://www.citrix.com/news.html.

Why would I use this as a title for a blog post? Because in our role as strategic consultants to end user companies (60-70% of CIMdata’s revenues in most years), we often help them to define their PLM strategies, develop requirements, and select and implement PLM-enabling solutions. In this role, we have front row seats to solution benchmarks, where the leading PLM solution suppliers are asked to show how their solutions can meet a set of customer-defined scenarios.

And this is why I chose the Hall of Fame catcher for my title. All of these companies should be like the Big Red Machine. Efficient. Talented. Complete. They should hit these meatballs out of the park. Why do we believe this? Because in our analyst role, we work directly with the large solution suppliers and we KNOW that their solutions can kill most of these scenarios. Unfortunately, their performance is often like the 1962 Mets, one of the worst baseball teams in history. (Sorry to say I am a Met fan.)

Why is this? One of the biggest issues is that they just do not listen or read. The benchmark scenarios we help clients develop are very detailed, and we work hard with them to make them clear. But, in most cases the solution suppliers ignore certain aspects of the scenario. There can be good reasons for this. Some do not have the necessary functionality to do it. Or it may require customization, and we typically encourage benchmark development to use out-of-the-box (OOTB) functionality.

More often it is a corollary to the theorem that the “P” in PLM is not product, it is politics. Incumbent solution suppliers often do not take these processes seriously, thinking their existing position or “wallet share” will protect them. That may often be true. But is it worth the risk of upsetting your customer when you could actually do a very good job?

Future posts will highlight “News from the Front” on specific good and bad performances we witnessed with our industrial clients. The stories are true, the names will be changed to protect the guilty.

This left me believing that a lot of what people referred to as engineering intent was really “geometric intent,” the steps that a person executed using their CAD solution of choice to create the desired result. As a lapsed mathematician, I knew that there were many geometric ways to skin the cat, if you will. You can get to a desired geometric end result using different transformations. How you got there was a function of what ways your chosen CAD solution provided to you, and you knowledge of how best to use them. That is not to say that there is NO engineering intent in these steps, it was just that what I was hearing was more about geometry than engineering.

One explicit way that engineering intent does get into models is through parametrics. The requirements that engineers start with can often be expressed by mathematical relationships between faces or other features in the model. Another is what some term “design in context,” where there are contraints on your model that result from the other adjacent parts and assemblies into which your part must fit.

So why is this important, and why did I choose the title of a 90s “chick flick” for this post? Because in the last few years, several CAD suppliers have introduced solutions that make it easier to repurpose, modify, and otherwise change existing geometry. Siemens PLM Software talks about Synchronous Technology. SpaceClaim is making a business around helping people downstream from geometry creation to tweak things to make them easier to use (like CAE analysts or manufacturing people or people in supply chains).

It is this issue that raises serious questions for me. How can downstream users modify existing geometry and really KNOW they are not doing so in a way that affects the true engineering intent? You can’t really embed all of that intent in the model, and downstream people may not know about the real requirements. If your analysis reveals a weakness in the structure, and the analyst can change that structure, how can you be sure that the resulting part still meets the original spec? This example is not so bad, because if they are in the same organization you can have it kick off an engineering change process to make
sure this happens.

But what about people outside your four walls and not so clearly under your control? Contract manufacturing organizations for instance. The results of such downstream changes could indeed be cruel to your organization. (Not sure that Reese, Ryan and Selma thought about this one.)

OK, if anybody is still listening, please explain to me the error of my ways. I look forward to the discussion.

So, just what is a seat? Airplane seat (many of us in the PLM economy see too many of those, don’t we?), car seat (my time with those is up, at least for while), and I hope to see the two seats on the right in my down time. And, I also do not mean a SEAT.

Almost all of the solution providers in the PLM space apportion at least some of their portfolio by the seat. Over the last couple years, PTC has changed the way they report their numbers, and in their prepared remarks they provide great detail on seats of their products. Some solution suppliers occasionally talk about average seat price (ASP). For example, Dassault Systèmes reports on seats and average seat price in their earnings calls, but for SolidWorks only. Siemens PLM Software claims “6.7 million licensed seats” in their press release boilerplate but don’t specify what kind of seats. Some PLM solution providers have recently changed from “named seats” from “concurrent seats,” another compound use of the core term “seat.” Some offer “concurrent” add-ons to named “seats.” And still others claim to never offer “enterprise seats.” Most of the solution suppliers I spoke to would LOVE to have a consistent answer, but agreeing on a consistent definition seems to be a problem. So why can’t we have that good, consistent definition of a “seat” or a “license”?

As I said above, defining a seat is in the eye of the beholder OR the one asking the question. If I am in marketing, a seat count is the maximum it could be in the wildest estimation to improve the perception of size: demo seats, free seats, academic seats, seats where dust comes out of the keyboard when people try to log on, just about anything. (It is sort of how they count attendance at the University of Michigan football games – anyone inside the fence is “at” that game, which includes vendors, the bands, referees, the whole shooting match.) While these types of figures are good for press release taglines and Websites, they are not often instructive to others who want such data to make decisions. That is not to say large numbers don’t affect decisions. It is a measure of solution provider longevity and a proxy for provider size. However, in our work with industrial clients, they often want measures of “seats” in their geography, country, industry, or some other slice they feel is relevant to their decision process.

Others in the PLM economy have another definition in mind: for which seats are end users actively paying maintenance? This is where solution providers make a large percentage of their revenues, and there are many other parties interested in just how that maintenance revenue gets made over time, like the financial community. For example, Jay Vleeschhouwer has been making such estimates for some time to the benefit of the financial community and other interested parties. (Thanks Jay.)

In recent conversations with PLM solution suppliers as part of the data gathering for our 2010 Market Analysis Report (MAR), I have asked most respondents about this topic. One said the purest definition would be commercial “seats” on maintenance. Commercial does not include academic seats, and no demos, trials, or others (like seats provided to partners). A commercial seat is defined as a seat of software under maintenance that is being used to develop products by industrial companies This commercial definition gets to “gainful” use in the PLM economy – one for which the holder most likely paid a license fee and continues to pay for maintenance (to get access to bug fixes, updates and other covered forms of support). Yes, academic use is important, but more as “seed corn” for the next generation of designers and engineers. The “on maintenance” part would even include open source players such as Aras who have no license fees.

If you are interested in selling hardware, you might need an entirely different answer. I recently spoke to a hardware solution provider selling devices for use with active 3D CAD seats. For them, the right measure is really on the number of “boxes” of a relatively recent vintage being used for CAD or analysis purposes that can make effective use of their offering. Commercial or academic might be irrelevant here, as long as the users have the need and cash to buy that device.

How would YOU like to see the “seat” defined? If you have such a number, how would it benefit your role in the PLM economy? Inquiring minds would like to know.

Oblogation -noun 1. a blog that a person is bound or obliged to create when they become an “analyst.”

It took a while to get this blog started, but here goes.

The creativity of analysts extends to creating models. (In a future post, I will include my obligatory 2×2 matrix.) Any analyst worth his or her salt will have a model or two in their pocket. Maybe that is one reason I enjoy this profession, as I firmly believe in using models. No, not that type of model (at least not in this space). Models in the sense of what does not appear until the tenth definition of the word “model” at dictionary.com:

10. a simplified representation of a system or phenomenon, as in the sciences or economics, with any hypotheses required to describe the system or explain the phenomenon, often mathematically.

Perhaps this comes from my background as a lapsed mathematician. But this interest in applying models to help explain concepts was heightened by my time at the Software Engineering Institute (SEI) at Carnegie Mellon University. (Just for giggles, type “Stan Przybylinski software technology transfer” into Google and you can see illustrations of my sordid conceptual past.)

The “model of the day” comes from my time at the SEI, and has its roots in communication theory. The model helps illustrate how technologies move from one organization to another, and provides a framework for studying how they mature as a result of multitudes of these “transactions”.  (Our goal was to determine how to best speed the maturation of SEI-developed and promoted technologies to improve software development and its application. Today, the best known SEI “technology” is the CMMi and its offshoots, which should be familiar to many in the software development community.) Here we are using the model for a different purpose: to represent the relationship between solution suppliers and end user organizations, in this case in the PLM space.

Companies of any type (the large bubbles) develop products for sale to their customers. In the case of PLM, Solution Suppliers develop offerings of different types to help End User companies reach their PLM objectives. The smaller bubble on the left represents the outward reaching functions of Solution Suppliers, like sales and marketing. They are the “boundary spanners” described in the innovation literature.

On the other side, End Users often have subgroups, task forces, ad-hoc committees and the like reaching in the opposite direction. Sometimes they too are boundary spanners (but often they are people with the time to be in the group). These are the parties to this transaction in the PLM Economy.

Analysts and consultants are, of course, other actors in the PLM Economy that try to play that boundary spanner role. CIMdata is one of them. But one of the things that fascinated me about CIMdata when I joined the first time in 2000 was that CIMdata sat right smack in the middle of the equation.

Groups like The Knowledge Capital Group, an analyst about analysts (say that five times fast), categorize analysts as sell side (Solution Suppliers) and buy side (End Users) on their own magic four-sector-box-with-dots thing. In their scheme, CIMdata would sit on the mid-line, which is not common. Of course, the other analyst firms do work across the line, either by special project, cross-cutting business unit or some other means.

One of the reasons to bring up this particular model is that it represents my philosophy and plans for this blog. My topics will range across this gap, with some focusing on Solution Suppliers and others on End Users, but always with a view across that span. Beyond that, I am always open to ideas for topics. I also hope to have some fun, and good conversations along the way. Speaking of conversations, my plan is to leave comments on this group un-moderated. Whether it stays that way is up to all of you.

Let the fun begin!