PLM (product Lifecycle Management) is a methodology used in Manufacturing in which the central concept is Lifecycle. Life is a cycle that starts from birth and continues with growth and finally death. For human beings, pregnancy is 9 months and birth a few hours (hopefully…). On the other hand, life expectancy at birth is about 100 times longer: latest estimates in developed countries are around 80 years! Carrying and delivering a child is a beautiful and painful moment of life but it is a moment: this is just the beginning of the story, just as the first software delivery is just the start.
Our customers wish to have beautiful and healthy pieces of software that adjust exactly to their Form, Fit and Function but more importantly, they need them to grow and mature with them. Our customers live and breathe PLM everyday as a central concept of their manufacturing business. We have learned from this concept and applied it to software development by creating a unique DevOps platform that allow us to be not only the prolific parents of hundreds of apps but also the caring parents that will accompany them all along their life journey.
What is the benefit?
Our customers make tractors, jewelry, spaceships, furniture… this is their job, not to produce and maintain software. The Wincom DevOps platform and the apps methodology allow them to have their Total Cost of Ownership (TCO) significantly lower, predictable and managed.
An important secondary effect is very interestingly pointed by John Papageorge in his post “What’s the real total Cost of Ownership of on-premise PLM software?”: the economic concept of “opportunity cost”. If you invest your money in in-house customized software solutions, you will not only get a poor ROI but you will also mobilize your resources on a task that is not your core business. The money you invested in support software, if invested in innovation in your core business, may have helped to make your company even more competitive in its industry and therefore increase your revenue: yet, somehow, you missed the opportunity.
A highly valuable lesson we learned from our manufacturing customers is that the birth is the first step of a long life(cycle) journey: this allowed us to be the parents of almost 300 software babies and more importantly support them as they grow up.
This post is the first of a series on how to apply manufacturing concepts to software developments.
I don’t know if you are much into fashion, but last year women jumpsuits were quite trendy and like pretty much every girl I know, I got one. Last week I wanted to wear it for a party, but due to too much good food over the holidays and a January lack of motivation to go the gym, it was a no go. I bitterly thought: I should have bought a pair of trousers, a blouse and a jacket as some of it would still probably fit!
As you are not reading Vogue but a blog about PLM, you are now thinking: what on earth is the connection with software? As a software company we are often given a list of features that a customer needs and they expect us to build a single solution to satisfy these requirements. The way this is normally done is a project is started and after several months of hard work, brainstorming, meetings, development, more meeting, testing, feedbacks, more meetings etc. you finally get a piece of software that more or less fits the original need.
However, the business, the requirements, the teams and related software systems never stop evolving and almost from day one, the delivered solution needs to evolve, enhance, extend and even some features need to be disregarded just to keep up; not to mention the inevitable upgrade of the PLM. That usually means more brainstorming, more meetings, testing, feedback. Very soon the total cost of ownership (TCO) starts to spiral out of control.
So… what if instead of purchasing this jumpsuit piece of software your requirement is divided into a series of apps that complement one another and, all together, provide you the perfect outfit? This solution has a lot of benefits:
– The apps implementation and deployment is much easier and therefore less costly.
– When you need to extend or enhance one aspect of your initial requirement, this can be done on just one app adding or changing this specific feature. This “surgical” approach also means a significant time and cost saving.
– If you no longer need part of the features you planned in the first place, the corresponding app can simply be uninstalled without touching any of the others.
– The result is a much more managed TCO and a big decrease of the associated ownership headaches
Apps are the trend in software, but to successfully deliver an app based solution means we must use a DevOps platform built using PLM ideas to make this a concept a reality and get us away from the monolithic spaghetti that most system turn into.
A fashion tip: Avoid jumpsuits and invest in more flexible solutions that can evolve with your shape and form… or your clothes will stay in the closet.
In your company you probably hear this type of question: “Where are my changes?”, “What is taking so long?” or “What is holding up the process?”… and many people saying basically “I don’t want to understand Windchill, but I need the information it holds”. That’s why we created the External App Platform where your management area, your services, your external partners or whoever you decide can actually see all this information without having to dig into the Windchill complexity to find it. As every customer has unique needs and requirements, we brand and configure the platform exactly to your needs. We can configure as many Platforms as you require: your executive management will not need to access the same information as your external partners!
This is why the External App Platform (EAP) is a Service-as-a-Product: You get exactly what you need, but it is supported and maintained as a product would be.
The EAP has different modules that you can plugin. The first one is Data View: it allows you to visualize the information you need about changes, state, etc. in graphs and tabs in a very user friendly interface. Every single column, row, type of graph is entirely configurable, and the best part is that you can export all this information in different formats (.csv, .xls, .pdf) and with our report engine even produce a hard-copy report:
Through our second module, Search, you can navigate easily through your structures:
Portal, (our third module) allows you to have instance access to CAD and Part data, and to the 3D visualization. More are in progress, such as a new Workflow Visualization module:
Finally we can make modules built-to-order, to match exactly what you might need.
Our EAP is currently in production in many large, international manufacturing companies from different fields as Agroindustry, Defense and Furnishing.
Interested? Request an online demo or an evaluation copy here! And please take a look at our App Center.
After 15 years working in PLM, we have seen that many PLM implementations are being delivered late and only after lots of pain for everyone involved and some projects fail to deliver anything at all. So why is PLM so hard to implement? Why are the projects almost always late? And how can we deliver a successful PLM on time?
Why projects are late and/or fail
Here are some common reasons why a PLM project is late or fails:
- Resources: getting the right ones with the right knowledge
- Unrealistic expectations of management and users
- Under-estimating the complexity of PLM
- It’s the fault of the software: we should have bought PTC, Dassault, Siemens etc.
- Delays of vendors to fix “critical” issues
- Technical problems that delay migration of data
There are many more but in essence it comes down to Project Management and resources, and in PLM the way we manage these things doesn’t seem to have changed in decades.
Let’s start at the beginning, scoping the project: how long will it take and how much will it cost?
Often, implementers are obsessed with counting man days. Most PLM projects are scoped in the same way, the implementer spends days or weeks producing a huge excel spreadsheet that has a large number of line items specifying each activity and the number of days that each will take. They add them up and triumphantly present a huge number of XXX days. The customer is shocked at the huge number and the next few weeks are spent trying to find “savings”. It is an archaic way of defining a project that assumes we know everything from the beginning. But how can this be right? How can we know what we don’t know before we even begin?
Over time, lots of project management ideas have come and gone to solve this failure to deliver PLM, such as Platforming, Critical chain, etc. which certainly improve things, but I propose we run our PLM projects as if the PLM team were a “Startup”.
“The Lean Startup” is one in a series of recent books that try to help entrepreneurs create and manage successful tech startups. The book has many ideas, but a key one is to get something to market as soon as possible so you can learn what you don’t know. The idea is not new, e.g. Agile software development methodology also promotes it, and ironically these methods basically reuse many ideas from Lean Manufacturing that the manufacturing industry itself invented. In “The Lean Startup”, this idea takes the form of a concept called the MVP, the Minimum Viable Product.
I propose we need to think about our PLM projects as the Minimum Viable PLM to make our projects a success.
What is a Minimum Viable PLM?
A Minimum Viable PLM is not a prototype, it is not a “bad” implementation, it is a production worthy system, but we have cut down the requirements to the core. Once it is in production, we rapidly move to improve the solution, fix issues and add features that make our PLM the fully featured system our users require.
So we need to learn from our users and fix our mistakes, but we also need to be brave and make decisions (even the wrong ones) to avoid analysis paralysis. It does require a responsive dynamic team to make it work,
So the question is “Could it work?”. Our experience tells us it does, as the following case study illustrates.
MVP Case study
A medium size French company that makes postal machines, implemented a successful PLM in 1 year, How?
A project manager who ruthlessly defined his MVP
An infrastructure that meant they could change their decisions, quickly and rapidly and learn from mistakes
A small highly focused team
A mechanism to release new software updates almost daily
Really good software people, a skilled implementation team (Accenture) and a fully engaged customer
At go live, our Minimum Viable PLM looked like the image below and was successfully used in production.
But that was not the end; two years after go live, it now looks like this:
Over time there have been issues but these have been rapidly resolved. More features are constantly being added and some will take more time such as a key goal to radically change the way products are designed using ETO (Engineer-to-Order); some things in PLM are just plain difficult.
MVP really works, we have seen it work and we know that even in projects that are traditionally scoped, it rapidly takes hold, by simply providing the tools to iterate quickly. However we must have the project management and technical expertise to support this concept and the bravery to make decisions that may be wrong.