With regards to your question there are so many follow-up's I can’t even list them here. So here is what I have (I’ll leave it to you to match it to whatever you’re looking at):
I currently have M2M deployed in house with many seats and have done so for over 8 years now.
We use M2M 5.6 on MS SQL2K SP4.
We use SFM (Shop Floor Manager) from M2M
We use SWI (SolidWorks Interface) from M2M
We use the M2M Gateway
We are using SW2008
We are in the process of installing PDMWorks Enterprise2008 with MS SQL2005.
1. Stay away from M2M 6.0. It’s still in beta right now.
2. As far as LCM. I just typed the phrases “LCM”, “life cycle”, and “life cycle management” in the knowledgebase and came up with “No knowledgebase results found based on your criteria.” Nor is there any mention of anything that addresses LCM in the product page. ERP, SCM, CRM, and Finance yes, but no LCM. I don’t know if you’re ISO9001 but if you are I don’t know if M2M can really address those needs. Your PDMWorks archiving, revision control and workflows with notifications will have to carry the load on that one.
3. There is actually very little that is native to M2M ERP system that integrates with SolidWorks. I would not recommend the additional cost for SWI (Solid Works Interface) right now. This product was developed for another ERP, not M2M. It shows promise and may be better in a few months but we are currently having issues akin to a development process.
4. One thing to look for when installing PDMWorks where M2M is present. Make sure the SQLDMO.dll is not the system32 folder (where M2M sometimes puts it). This made us unable to use PDMWorks Enterprise Administrator console on any clients where M2M was present. PDMWorks also uses that file and by default looks in the system32 folder. It will find that it is incompatible.
5. When you look at your Item Master under the Engineering Tab you will find that there are fields to define where files are located for that part. We use this extensively for engineering files and other things that require automation and manual access. Why is this a problem with M2M? Because if you tell M2M that a DXF is located in your vault you will be unable to access the vault directly. Because it is not actually there, only items cached actually exist as a file.
For those without PDMWorks, this is a hard one to explain. Windows functionality is a word that is used a lot in PDMWorks. We call it “The VooDoo Screen”. What you see in a folder in Windows is a “View” and not actually there, nor does it have all the files therein. It is a Visual representation of a Query that tells you what is available to you either “Cached” (local) or “Vaulted” (locked, managed and renamed in a DB). This is where the PDMWorks View mixes the truth with lies.
To work around this, we have to “get latest version”, using a shortcut to the “View” (c:\Martin Test Vault\SW\Products) before using the links in M2M.
Also, you cannot map to the PDM via Windows. You can only map, old school style, using your command line like the following: C:\> net use X: “ \\Client\c$\Martin Test Vault\SW\Products” .
The location on C is where my “View” is established. This is the local cache NOT the entire vault. The direct route and the map will show totally different results. When I look at my “View” via explorer I see everything. However, when I look at my mapped drive, its contents contain only items that were cached. This is where it gets relatively complex for an average user.
There are a ton of other items to address but without further consideration on product, compliances, versions and other gross subjects this is where I will leave it. This is more than I ever got before I bought into all these Silver Bullet Solutions from various sales weasels.
BTW...To anyone that may disagree, I will be happy to retract and/or extol the virtues of anything above if it can be PROVEN to me that anything I posted is wrong. And not with some theoretical, circular logic, mumbo jumbo but actually proven to me with proof of concept case examples.
