When screening tweetstream yesterday, I caught CIMdata’s Stan Przybylinski question on twitter “What % of product development data authored and/or resides in Microsoft products (Office, Exchange)? Thinking IP not number of files or megabytes“. The question itself is interesting. How to measure the % of IP? And how IP is created?
It made me think about IP creating paradigms and engineering software. Decades ago, before computers came to organizations, IP was created in engineering and drafting offices. I remember the office my dad was working in decades ago. The picture above (credit to Armstrong Siddeley car and aircraft engine works) can give you an idea of what was that. IP was created on paper and it was visible. I remember how my dad was walking alongside of drawing boards to review project progress. Processes were visible too – notes and papers were moving around and clipped on drawing boards.
Benedict Evans’ blog Office, Messaging and Verbs brings an interesting perspective on evolution of productivity applications and changing paradigms. My favorite passage is related to evolution of tools and changing the way to address the same business problem.
When people talk about productivity – about PowerPoint and Excel and how Google Docs and the cloud will or won’t kill them, or messaging and the cloud, or how you need a PC for ‘real work’ – I’m reminded of CC Baxter and his Friden calculating machine. What killed those machines was not better, cheaper competitors but a completely different way to address the same underlying business need. Instead of hundreds of people recalculating insurance rates, the company bought a mainframe. The business need was being met, but the mechanism changed completely and the old tools disappeared.
That is, the way forward for productivity is probably not to take software applications and document models that were conceived and built in a non-networked age and put them into the cloud, or to make carbon copies of them as web apps. This is no different to using your PC to do the same things you used your typewriter for. And of course that is exactly how a lot of people used their PCs – to start with. Just as today we make web app copies of software models conceived for the floppy disk, so the first PCs were often used to type up memos that were then printed out and sent though internal mail. It took time for email to replace internal mail and even longer for people to stop emailing Word files as attachments. Equally, we went from typing expense forms (with carbon copies) to entering them into a Word doc version of the form, to a dedicated Windows app that looked just like the form, to a web page that looked just like the form – and then, suddenly, someone worked out that maybe you should just take a photo of the receipt. It takes time, but sooner or later we stop replicating the old methods with the new tools and find new methods to fit the new tools.
Tools following workflow and then overtime changing the workflow itself. I can see it happening in engineering software too. Drafting paradigm created 2D CAD drafting software, which later on changed and transformed into 3D modeling tools. Despite many earlier predictions, 2D is not dead and many engineering and manufacturing companies are still using 2D paradigm to fit their working processes.
PLM tools were born in large companies to solve complex configuration management processes – to manage complexity of data and changes. Therefore PLM systems we have today is a reflection of existing workflows. Tools just reflecting existing working processes. Now, it is a time to for tools to evolve and change existing workflows.
I want to come back to my observations about problems with “analog PLM”. This is what we have today. Existing PLM systems are actually a reflection of existing workflows. We are getting into “better” version of existing workflows and tools. But, better and cheaper version cannot create a change. This is exactly the same point I’ve made in my blog about what cloud PLM cannot do for you. Yes, cloud PLM is better than on-premise systems. But this is still the same way to solve business problem.
What is my conclusion? Existing PLM systems built around two fundamental paradigms – product model and message workflows. Although these models are very fundamental, they are reflection of paper oriented models engineers used before computers came to our working environment. For the past 20-25 years, CAD digital models shifted existing workflows and created new design paradigms and environments – 3D design, simulation, etc. Existing PLM environments are complex. It takes long time to setup and it is hard to use. In my view, product lifecycle management is still waiting for new digital paradigms to take over existing workflow message flow. Just my thoughts…
Best, Oleg
