I personally spend a lot of time wondering how we could provide better solutions to our customers and to the industry in general. I look at what we provide and yes there is always something I would like to enhance in the product. The issue is we, at Minerva, are mainly integrator and the best impact we can have on products like Aras Innovator, is based on the feedback and enhancement request we raise. But then we are not the editors so we are not making the decisions. So as an engineer and talking about PLM and PLM software I’m always interested in imagining how PLM could be better.
I’m not a database specialist, so this one will be short. I already mentioned in a recent article the graph databases which may have an important impact on how the objects interact and how permissions and contextual views can be managed. But I think today, the issue does not necessarily come from this point.
Access & Permissions is a key asset
But one key asset that is complicated to setup and for which a solution like Aras Innovator has been well design at initial design is the Access & Permission strategy that they’ve been implementing. There are still some issues that can be entirely leveraged by custom code inside Aras if needed. We recently use this capability at one of our customer to build very flexible workflows for which their legacy system provider is not able to match. So this is where my dreams of a very simple solutions developed in days are stopped. I realize that it takes a lot to build this access management system. And that’s why If you put a little energy in trying Aras, you’ll see that not only tomorrow but even a few years from now you’ll still be able to setup access & permissions for your users in a fast moving economy environment.
I already wrote about lean strategies related to PLM solution deployment and also the article about not starting a PLM project from Engineering, and I’m apparently not done on that topic based on this new article. Lots of comments were made on me being mad when willing to start PLM out of Engineering and at the same time very experienced people took the arguments, faced these arguments with the existing projects and realize there were some good points which were making sense and could be applied. Last week-end as I was helping a brother to start building a fence, working with others, we made sure we were pulling production to reduce moments where you wait holding some heavy stuffs and it brought me back to the lean topic.
The manufacturing / Engineering interface issues
This is something we always ear and mainly when there is a new cad designer in the company, it is not that easy to design stuff that the company can produce. Being good at designing product that can be manufactured requires experience, knowledge about manuufacturing and industrialization and also about your own factory’s ressources. So the main cause is usually experience, but what if the systems were made to provide more information and more constraint to the designer? Before designing, should he get to know what’s available in manufacturing or if there is a new machine to purchase, should he bring enough information to provide the right data? This is said to be good practices that designer should have. I would say that these are requirements from manufacturing.
The lean concept is highly based on a pull flow. Most of the arguments I’ve had were about the fact that the main data is created in Engineering so we should start deployment in engineering. Well, what if you should provide a system to the first person who enter the system. The one who will pull the flow, the customer? the marketing? assistance & support?
Impact on deployment
PLM editors have been working a lot on integrating requirement management solutions lately and this might be some of the features to implement first. We have started projects from the Change Management. Has there are existing parts, prototypes and products instead of changing a whole existing system to provide a solution for engineering we may want to start by capturing the daily change request and problem reports. And then you would continue the implementation rolling back the product lifecycle.
Have any experience of project which may have run in this way?
Versionning is always tricky in organisations and this is true for a lot of different environment. You can either be in sales, logistics, engineering, maintenance, HR,etc. There is also an issue with versionning. And it is strange because best practices have been discussed a lot, but it is sometimes hard for people to have a common way to think about versionning. I was recently discussing with a colleague with whom we are working on a new interface where the versionning is to be shown and available to the user. And as he comes more from a software development environement and I’ve been 100% in PLM without to much including source code management, we realized we had a different feeling about versionning.
Difference of intentions
It is funny, because I hear more and more leads and customers talking about intentions when they want to describe a software and that was exactly my feeling when we stumbled upon this difference on how we thought about versionning.
- For the software development oriented person, versionning means saving or tagging. It means that the actual work has to be saved because we want to keep a state of the actual work. “I want to keep a state, I make a version, this version is stored”
- In my view, related to main PLM concepts, versionning is creating something new. “I want to start a new work or I want to change a document, I version it. my new version is my working copy”.
The difference is not that big, but the difference of intention in the term “versionning” is surprisingly quite important.
We realized that it could be just a matter of interface because the backend can have the same logic. The issue is that we were on a software which would be used by users from different departments and with different experiences but where we couldn’t have two interfaces. So it needed some discussions to make sure we understood the same concepts and we would make compromise to use one single software interface on that product.
What is your “version” of “versionning” ?
Happy new year to everyone. I hope the actual economy environnement will convince more people to invest time for helping the product development initiatives by solving Product Lifecycle Management related pending issues. Today’s article is about my thought on why it is always so complicated to move from a PLM solution to another, why are we changing tons of things and settings to in fact change a software cost or an interface. On of the reason is that all these elements are strictly related and the elements in a PLM solution can’t be dissociate. You can’t just keep you data and change the interface. From my previous experiences of migration, I’ve realized that I was moving data from a system to another with transformations but the data would still mean the same thing it is just that the software would handle it differently. Then speaking of standards would there be a standard for data management in PLM and should this define a technology or at least should it drive database system editors to push for one?
Today we mainly use SQL databases with tables in databases. Two schemas are used. Either the schema with a constant number of table like “value”, “properties”, “table_name”,… which allows you to create any complexity of system with a constant number of table. Or you have the schema like the one used by Aras Innovator which has one table for each Itemtype. Th
New database solutions
These solutions may not be new but they are not used so far in PLM systems. The main difference that I see is that it is taken into account that a part and a relationship between two parts can’t be stored the same way. Plus, we are use to have very simple relationships parent-children with sometime one or two other type of relationship but what if tomorrow the objects behave much more on context and you need to define these with more flexibility.
- One first alternativ would be to store everything in XML databases. Most of the standards are using XML to be described why shouldn’t we store them directly in XML. Here is a presentation of BaseX.
- The second one much newer and with nice perspective is shown in the following video where it says how they care about relationships in a different way then usual and with a lot of inputs from the actual developments in the social web.
I didn’t want here to get to deep in the tech talk about databases. Just starting some more thought about what could be the next technology to use to help customers to have a real matching between the real world and their databases and then to have more chances to detach the interface and the data. What are your thoughts?