Design and Manufacturing solutions through Digital Prototyping and Interoperability

Category Archives: Management

Management of design, engineering, manufacturing, simulation, and construction data, including 3D CAD models.

The more things change, the more they stay the same?

Just before I went on vacation Jonathan Landeros (Inventor Tales) posted a great article about old technology vs. new technology – how new doesn’t always mean better. It should really be about picking the right tool for the job. On my vacation the family and I went away for 7-days to Prince Albert National Park (Waskesui) and I left my computer(s) at home. I still had my phone, so I wasn’t completely disconnected, but with no laptop at my disposal it left me lots of time to think and contemplate things.

What I ended up thinking the most about was my day job and the current technology at use. What I mean from this is that we are not adopting new technology and processes, we’re not even evaluating or considering most of them. Why is that? and is this ok? I also though about the current “rut” that I was starting to feel, from a technology standpoint. Which is odd as I never have considered myself bleeding edge, but I’ve always felt that I’ve had a good handle of what was going on….. but now? I’m starting to feel left behind.


So what “new” technologies am I thinking about? The Cloud

, Robotics / AI / Drones, Electric Power, 3D Printing / Additive Manufacturing, New Materials, IoT (Internet of Things), Easier more integrated access to CAD / CAM / FEA / Visualization, and the the blurring of lines between BOM / PDM / PLM / ERP / MRP / CRM / add acronym here. There is also generative design and many other unbelievable things happening.

There is also the change in how business is being done… crowd sourcing, crowd design, open source new-shoring, …. and the blurring of what’s public and what’s private. What does Intellectual Property (IP) really even mean anymore?

Change happens, and hopefully when it happens its a good thing. At my day job what really changed things for us was the acquisition of an electrical vehicle manufacturer. This has made us look at how we do things differently, and how we can approve. The status quo is no longer the status quo, which is good as one never wants to become stagnant. The new mine being built in the province has mandated 80% electric use for machinery and equipment, with a clear goal to exceed this. What an opportunity for us!

As you can see I was thinking about a lot! But also note that not everything is new, some items have been around for years but are just now becoming mainstream.


I’m going to embark on a series of posts exploring each of these trends and the new technology. I am far from the expert which I think makes it great as there will be plenty of opportunity for feedback. What has worked? What are you looking at? How are you approaching it? I want to explore how to approach the new technology from an individual personal and professional aspect as well as why companies may or may not look at the new tech.

For this series we’ll use an example company “ACME Mining Equipment”, that I’ve made up, but I don’t think is that dissimilar to a lot of small to medium companies. Here’s their profile:

ACME Mining Equipment is a  company that primarily manufactures, repairs, and services underground mining equipment. The company started as a custom machine / fab shop over 35-years ago. They have one facility and around 150 employees. They have a very small, but very loyal customer base, many whom we’ve done business with for over 35-years. ACME (or AME) is classified as a small, engineered-to-order, manufacturer (at least as far as ERP companies classify things) as they customize just about everything that goes out the door to meet their customers requirements. The customization is what separates ACME from their bigger competition that just pushes “boxes” out the door.

  • ACME is an Autodesk shop – through-and-through – they use Inventor, AutoCAD Electrical, AutoCAD Mechanical, Vault Professional, Simulation Mechanical, and even have a few seats of PLM 360 floating about.
  • They make things from purchased items and steel (laser / plasma cut profiles & standard structural shapes). Welded or bolted together
  • Although they have some CNC capabilities, most of the programming is done by hand on their NC machines (for various reasons – I’ll explain more later)
  • Communication with the customer is done mainly via the phone and email. Outside of quotes, sales order confirmations, and manuals very little other types of documentation are exchanged.

Keep watching the site!

All imagery from GRATISOGRAPHY

Document. All. The. Things.

I recently saw an opportunity to join one of the UK’s leading Autodesk Platinum resellers, Graitec and the sudden move jogged me into thinking about the tools I have created in my two-year tenure at my current post of CAD Engineer at Matrix Precision Engineering Ltd. based in Thatcham, UK.

In particular, it forced me to begin the sometimes-onerous task of documenting the tools I created along the way. This led me to tweeting the following:

A week or so passed and there followed another tweet this time regarding the AUGI survey results due to be published shortly in their “Hotnews” segment:

By this time, I was neck-deep in writing several documents that (I hope) will guide my soon to be ex-colleagues in using the tools I built and, coupled with the series of replies that followed the latest tweet above, the whole situation got me thinking about this post.

When is the best time to start writing documentation/processes and procedures?

For me, documenting the software I’ve written has up until now been a “For my eyes only” approach; wherein I document or more accurately comment the code as needed and do no more than that. As I prepared to leave my previous post (prior to joining Matrix), many of the tools/processes I had created were already out of use, primarily because the project they had been used upon had ended. This time around, the team I am leaving is in the infancy of getting to grips with helping their client understand exactly how they need to use Inventor/Vault Professional alongside their existing legacy data.

This leaves me with a challenge I hadn’t expected to face when I wrote the four main pieces of software, that I now find myself some 75% of the way through writing guides for:

What’s the best way to write a document about something I created, when my intimate knowledge of the subject could lead to many oversights/omissions in the documentation, based on assumed knowledge about a template/pre-requisite?

On this occasion, owing to the fact that we’ve been writing a document aimed at which capturing every intricacy we have encountered on behalf of the clients’ dataset, I chose to use Microsoft Word, stored in an instance of Autodesk Vault Professional 2014.

Whilst it seems on the surface to be a good match, there are multiple issues with doing it this way, not-least the fact that none of my colleagues can see what I’ve added to the file until I either check it back into the Vault or email a copy round for people to make their own notes on. In future, I think I would prefer to use Microsoft SharePoint, as it allows a more collaborative approach not available in Autodesk Vault.

In addition, everyone has their own style when it comes to writing documents of this type, so here are my top tips for writing the best documentation you can:

Is it simply code or a workflow involving multiple steps?

The reason for this differentiation is that if all you have created is (for instance) an Inventor iLogic rule, chances are the complexity of said rule will be such that anyone with a competent understanding of iLogic, should be able to figure out what it is doing based on the minimal amount of comments within the code. This of course depends on the person writing the iLogic using a Really Obvious Code (ROC) approach.

If your creation is more than simply iLogic, there comes a point where commenting the code is not going to get the necessary level of understanding from your audience for them to be able to use the tool in your absence. The technical nature of your workflow determines when and where exactly you reach this point.

When the workflow is:

  1. get external iLogic rule from Vault
  2. open file (assembly or part)
  3. add external rule to Inventor
  4. run rule

I would say there is little need to document these steps over and above a single page of A4.

If however, the above iLogic example were to rely on other pre-requisites such as Microsoft Excel templates and an understanding of (in our case) the clients’ parts list numbering schema, then there is a benefit to the team in documenting the workflow in its entirety.

Treat the audience as if they are new staff

Unless you’re prone to showing off during your workflow creation, there will be very few staff who will have any idea what the workflow you have created is capable of doing, let alone how it is doing what it does. My advice is to take a view that although the team member using the new process will be competent in their main role/software (in this case, Inventor) anything you have created will be completely new to them.

My current example of this is for a workflow I created that takes a folder structure based on pdf file names, pairs it with an Excel spreadsheet containing the relevant metadata, then builds an Inventor assembly that matches the structure. I quickly figured out a number of steps required to get the data in a useful format, and rename the files (sometimes 1000+) for each project.

What I had overlooked was exactly what tools and pre-requisites I had been using as part of this workflow, it having been some time since I had first installed them. The first draft of my document had skipped over these details because these tools were so ingrained to me that they had become second nature to make it all work.

Ask a colleague to use the workflow (and accompanying guide) on their workstation

This may not always be possible as your office might not have anyone spare to test the documentation, but for the sake of your team, I believe this step is necessary if you are determined to have a robust, user-friendly guide that covers every step required to carry out the workflow correctly.

In the event that you are not able to have someone test the workflow, there are a number of potential solutions available. These range in complexity from simply asking one of your co-workers to swap desks for a period (whilst you complete the guide), to creating a temporary user account on your current workstation (mild difficulty), to setting up a virtual machine on your workstation. Obviously, the last option is fraught with its own issues, but I truly feel all these steps are worthwhile in the long term; especially if you wish to avoid a phone call in x number of months after you departed the company asking you why workflow/tool x has stopped working.

Get to know the tools and document why you used them

Revisiting the software that forms part of the workflow I had been documenting; it is important to note that although the help guides for most software will be comprehensive, it is best to leave nothing to chance. Where possible it helps to explain some of the underlying uses of the technology/techniques you have used, to help the user better understand how it all works. This extra information will aid the team should something change down the line.

The best example I have for this is Regular Expression.

Google defines Regular Expression as:

regular expression

An example of a simple regular expression (regex) is:

Wherein the “.” Signifies any single character and the “*” matches the previous character zero or more times.

If your workflow finds you needing to work with any kind of text string, be it file names, drawing numbers, or other metadata that contains multiple pieces of information, regex is just the ticket.

As part of my workflow I had a file name that also included the Assembly level of that file:

1-1 DWG-NUMBER Sheet-Number Issue-Number.pdf

Regular expression let me remove the first part with the following simple match:

Wherein the match can be broken down by the site as:


This returns the following match information:


Which as you can see gives us the correctly named .pdf file (Match 2 above)

In the workflow I have been documenting, regex is useful in both Microsoft Excel (with the addition of the Regex Find Replace Addin) and in the Bulk Rename Utility <- a tool which does exactly as the name suggests.

The addition of extra information such as this makes any user guide so much more useful than simply saying “insert this into this cell and hit enter”, as it builds a level of understanding with the user of said guide that is otherwise not available.

This understanding is useful for future situations not already covered by the workflow or workflows you leant your skills to help create.


If I were to boil these points down into a simple list it would be:

  1. Make documenting your workflows/tools part of your team’s standard procedure list
  2. If your workflow involves a software tool you created, assuming you have followed a ROC approach, there should be little need for excessive explanation
  3. If you make use of a particular technique or piece of software (in this case regex) as part of the workflow, it will help if you explain in detail how and why you used it
  4. Have a colleague test the workflow using your documentation when you are finished; it will help highlight any areas that need further explanation/detail

If this experience has taught me anything it’s that I should always practice what I preach. I hadn’t really given the documentation a moment’s thought before deciding to move to my new job. Having to write documentation for workflows I knew intimately, forced me to consider in great detail all of the steps I had gotten so used to using along the way, and thanks to my (ex) colleagues’ feedback, there now exists a comprehensive guide for each of the most-useful workflows I have left behind.

Writing all of these points down will hopefully serve as a useful reminder to both myself and you the reader in future.

A Story of Implementation – Making the Selection and Hitting the Homerun

If you’ve been following along with this series (see the last one here) you know that I was tasked with finding a replacement for our aging ERP system. It needed to be something that would set up the company for the foreseeable future. I wasn’t doing this alone, but it was my responsibility to build a credible list of vendors. Using many factors I built a list of six, what we felt were, strong contenders.

Even though we had received upper management’s approval to start the exploratory process it was decided to do a “check-in” with the board of directors. This provided the opportunity to highlight the list of ERP possibilities, ball park pricing, our criteria for making the selection, and the next steps. This is an important part of the ERP selection process as it has been shown that one of the main causes of ERP failures is a lack of top management commitment. It is important that the “top” understand key events and truly understand (appreciate) the size and scope of implementing ERP. They need to understand the commitment of time required, it is no small undertaking.

ERP Gate

ERP Gate by Karl Baron  

With management’s approval we kicked into high gear on the selection process. A small evaluation team was created. We decided to keep the group small… lean & mean… to keep focus. We’re a company of around 150 employees with only one location, so for us the group was five people. We had representation from finance, production, engineering, IT, and upper management. I was the team lead and overarching presence to keep the group focused and look at it from all angles.

The demo process started. Two of the vendors provided a “canned” style demo asking very little questions about our business first. The other four put us through various levels of “discovery” to better prepare for the demo, to get an understanding of our business and how ERP was going to help.

The “discovery” process is very important. The ERP vendor needs to understand the requirements so that they present the right combination of modules, processes, and workflows. As a potential customer of ERP you need to define a comprehensive list of requirements…. you need to know what you are looking for and you need to communicate this to the possible ERP suitors. Not that it can’t evolve as you see the solutions, but this list of requirements needs to be developed before the demo process begins. Another big cause of failed ERP implementations is picking the wrong solution, so make sure you, your team, and the vendor are working from the same page.

The demo process takes time, and for us involved multiple demos from each vendor. Think of it as the swimsuit portion of the pageant. Everyone is strutting the runway trying to look their best, but you’re really just evaluating what you can see..

You need commitment from your selection committee not only to “sit through” the demo, but ask follow-up questions and to provide feedback on what they saw and liked and what they did not like.

As mentioned earlier we had narrowed the selection to six possibilities. Three of these were scratched off the list very early. One was clearly optimized for high-volume production, not an engineered-to-order business like ours. One was very strong from a job management perspective, but we wanted more than just a “job shop” system. The last of the three scratched off the list had a poor team and did not give us the confidence that they could successfully aid us in implementing the solution successfully.

After the initial rounds of demos we were left with three serious contenders. To our surprise one of the vendors drifted, and although never admitted to anything, basically gave up trying to win our business. I’m not sure if they were too busy, we were too small, or they did not want to compete with the other two solutions. This left us with the final two.


Choices by Dan Moyle

Now it was time for the interview portion of the ERP pageant. With the two “finalists” we had onsite visits, extended “discoveries”, we contacted references, and we got very specific feature demos and walkthroughs. During this time each vendor supplied quotes and we started to detail what the implementation was going to take in time and money.

Now the hardest decision to make. We had done our due diligence and it resulted in two very strong contenders. We, as a selection committee, went back-and-forth on an almost daily occurrence. It was stressful actually, trying to weigh the pros and cons of each, trying to find the right solution.

[Looking back I wonder if there was really a bad choice. If we hummed and hahed between the two, they must have been very close in features, functions, and workflows.]

Lose Your Sleep Before Your Decision

Scott McLeod – Lose your sleep before your decision, not after it

So how did we make the final decision? The two offerings were neck-and-neck, except one package (the one we chose) had a far superior scheduling offering than the other, and for us that was a big deal.

As the last test we had the selected ERP vendor (although they didn’t know it yet) demo the product to an extended group of our employees. We included every supervisor, planner, purchaser, financial person, HR, quality, Engineering management, and upper management. What we received was an overwhelming vote of confidence and actual excitement of the possibility. With this feedback we had made our choice.

Now it was time to make the final decision on making the jump to the new system, but that is a story for another time.

Feature Image – Deciding Which Door to Choose 2 

A Story of Implementation – Narrowing the Field

You might be wondering why I’m doing this. Why I am documenting the process we went through to select and then implement an ERP solution. I’m doing this as I hope it helps others with their selection. Picking an ERP system is tough and its a lot of pressure. You are spending a lot of money to not only purchase the software but to have it implemented. As well, if you’ve chosen the wrong system or implemented it poorly, it’ll end up costing a lot of money later on. I know, I know, way to sell it, eh? But don’t fear, for every failed ERP implementation there are probably 10 other successful ones. It can work and if done right will work for you too.

If you’ve been following along with this series you have already:

Once you’ve narrowed the field to an ERP market segment, you can start to weeding out the outliers that don’t fit for you. With some Google searches and visiting each solutions website, you’ll quickly build up a sense of what you like and what you don’t like. You should aim for a list of 10 or less, which might still seem like a lot, but honestly it is a good starting point.

White Board Markers Presentation Strategic PlanningWhite Board Markers Presentation Strategic Planning

What we did next was started talking to our customers and suppliers. We asked what they were using and asked what they liked and didn’t like about the system. We asked questions about the implementation, if they did it themselves or if they hired someone to help. We asked if they were current with the version. Finally, we asked how long it took to implement.  In conjunction with this I started using social media and the good old phone to reach out to friends and contacts I’ve made over the years in the CAD industry. These weren’t necessarily CAD people, but it put me into contact with people who knew what their organization was using and in some cases they put me into contact with the people who were responsible for ERP at the organization.

In talking with these people, we started to see a trend on what was the most used solutions. The ones who provided positive feedback on their current solutions also lead us to looking more closely at certain systems. This got us to a list of what we felt were six really strong candidates.

The Straight and Narrow WayThe Straight and Narrow Way

With the list in hand, we started clicking the Contact Me option on each website. This put us in touch with each vendor and I started getting inundated with pdf reports, case studies, product spec sheets, and other information on why we should be using ERP and why we should be using their systems. I used the opportunity early on to get “ballpark” pricing on each system, as I wanted to make sure that we had the right expectations on what it was going to cost us.

Very unintentionally, and completely by chance, one of the vendors sent us an “independent” study of why their system was the best. It was “independent” in that it was written by someone else, but it was paid for by the vendor, so it was very jaded in its view. However, this report provided the ultimate list in what we should be looking for in each system. Our initial intention was to grade each system using the checklist, but this became a daunting task so we decided to just grade each system by section instead. Still, this “find” sure saved us a lot of time. You may not be as “lucky” as us in receiving a list like this, but using the documentation you receive from each vendor, start to compile a check list of things that you want each system to have or to do. This will be handy when you start the demo process.

So between your discussions with the ERP vendors and with others in your industry you want to reduce the list to 6 or less. This will put you into a good position to start the demo process.

A Story of Implementation – Where Do I Fit in this Complex ERP World?

When we started the search for an ERP solution, I knew it was going to be difficult. Where does a person start? It is a crazy, crazy ERP world out there. Don’t believe me? Try this: go to the google homepage, type ERP, and hit search. The results “about 142,000,000 results (0.38 seconds).

This is an ongoing series on the selection process we used to make our ERP choice. My goal is to help others about to embark on this journey. It is not an easy decision.

To recap the previous article, this is how we began our journey into ERP.

  1. We documented our current processes.
  2. We created a list (high-level) of what we did well and where we needed to improve
  3. We created a list (high-level) of what our current collection of systems did well and where it lacked
  4. We got management’s approval to explore ERP

So like everything else in life I need to research, I started with a good friend, Google. I typed in ERP, hit enter, and was immediately overwhelmed. The list was daunting. The number of companies offering ERP products, ERP research, or ERP selection services is outstanding. Where does a person start?

ERP Segment

What I noticed very quickly, is that the ERP market is very segmented. This segmentation is good because it significantly narrows the search. Finding the right piece of the ERP market pie, makes the selection process easier.

perfect pumpkin pie

 Creamy, smooth, slightly spicy… perfect pumpkin pie

First question to ask: are you government? in the public sector? a non-profit organization? or in the medical field? looking for a Retail system or Wholesale Distribution?. Are you a solely professional services organization? If the answer is yes to any of the above there is special segment of the ERP pie just for you. You should be searching within just these fields, contacting the companies that focus on these industries.

If you don’t fall into one of the above sections, then you have a few more things to figure out. We fall solely in the manufacturing realm. The manufacturing piece of the ERP pie is significant and probably the biggest sector of ERP. To narrow this further, you need to determine:

  1. the size of your organization (small, medium, or large)
  2. the type of manufacturing you perform.
  3. do you want cloud, no cloud, or a self-hosted solution?

Company Size

The description of size varies a bit depending on the ERP vendor, but the two common determinants are the number of people and the annual sales. As a company of 150ish employees all in one location, we easily fit into the “small” category. This knocks off the “big boys” from the list, the SAP’s, the Oracles, etc that are big-business, and do big-business well.

Type of Manufacturing

Now that size is determined, what about the type of manufacturing?

Are you a discrete, process, or mixed-mode manufacturer?

  • Discrete is the assembly of products from distinct items, think building a bicycle with nuts, bolts, the tires, etc. This is very Bill of Material (BOM) centric.
  • Process manufacturer blend liquids or formulas. Examples would be food manufacturers, chemicals, paints, etc.
  • Mixed-mode is a combination of discrete and process.

Are you Engineered-to-order (ETO), Make-to-order (MTO), Make-to-stock, or are you a job shop?

  • ETO is where the product is made based on very specific customer requirements. The products are typically complex and require the involvement of the customer from project start to finish. Lot size is very small as ETO is not well suited for mass production.
  • Make-to-order (MTO) or Build-to-Order (BTO) differs from ETO in that it is production focused opposed to engineering focused. Most components are stocked and only the high-expensive or high-customized components are manufactured to order.
  • Make-to-Stock or Assemble-to-order (ATO) is where all components and sub-assemblies are built, in stock and are assembled when the customer places the order. Customer involvement is limited, typically only at the start where they select the options or configuration they want from a predefined list. This is also referred to as light-assembly and / or kitting.
  • Job Shops focus on many, custom products or jobs. Each job is typically unique requiring its own set-up and routing steps. Lot sizes are small.

Most ERP vendors will claim to do all of the above, but you need to be careful as they all have their strengths and weaknesses. Some excel in certain types where others perform equally average across all of them.

As a manufacturer of mining equipment, but with roots as a custom machine shop, we are definitely a discreet manufacturer but fit into both the ETO and Job Shop fields. So even though we straddle two types of manufacturing, we were able to weed out the outliners that didn’t address our types of manufacturing well.

To Cloud or Not To Cloud

Finally, to cloud or not to cloud, that is the question. Most ERP systems today are self-hosted with a web connecting type portal. However, the are some now (like Netsuite) that are 100% hosted in the cloud. Others are optionally hosted internally or in the cloud. You need to ask yourself if you need to access your ERP 24/7 | 365 from anywhere.


 Cloudy by Kima

As a single manufacturing plant, with no other locations or offices, having a cloud-based solution was not desired.. Not that we were opposed, but it just made more sense to have a locally hosted system that could potentially be accessed from the outside world. The biggest reason was even if the internet went down we can continue working.

So before starting your search ask yourself if being “in the cloud” is an advantage for your organization. If it is, then focus initially on cloud-based solutions, if you do not want to be in the cloud then scratch these companies off the list.

In Conclusion

Finding the right ERP partner is a daunting task. It is hard, there’s a lot of pressure, and potentially a lot riding on making the right choice. It’s kinda like being at the bakery trying to pick out that one piece of pie. But by asking the right questions and knowing who you are, you can narrow the field to a few, making the decision that much easier.

plan dont panic

Plan: Don’t Panic

Autodesk Inventor 2016 Now Uses AnyCAD format

Ok, not quite anyCAD format, but all the really important ones are covered; Solidworks, CATIA, NX, Pro Engineer and PTC Creo. Hey, what did you say? you may be asking… Yes Autodesk Inventor 2016 will now natively import and maintain associativity with all major CAD file formats. BOOM! Now that guys & gals, is a game changer for the wider CAD / CAM industry.

Autodesk Inventor 2016 Multi-CAD

Why’s it a Game Changer?

There are plenty multi-CAD workplaces knocking about, whether that’s because of mergers, legacy decisions in different departments or a heavy reliance on contract design staff. But this is also a big deal for the CAM users out there, those guys are receiving various data formats from all their clients every day… and they are also subject to in process change just like everyone else is.

In the way the Navisworks changed the way multi-disciplinary design review was carried out forever (and it’s competitors), Autodesk Inventor’s Multi-CAD functionality promises to do the same for the modelling process itself. Yes, PTC got in there first with Creo 3.0 delivering their Unite Technology supporting Solidworks, CATIA and NX files. Inventor 2016 supports those same file formats, as well as PTC Creo, Pro Engineer Wildfire and Autodesk Alias. I never got the opportunity to try out Unite in Creo 3.0, so I can’t compare real-world functionality unfortunately.

How does it work?

I have absolutely no clue, beyond knowing the translators in use are from a 3rd party* (which other CAD vendors will also be using) and a heavy dose of wizardry from the Autodesk developers! What I do know, is you can open any of the supported file types, either parts or assemblies, straight into an Inventor part or assembly. You even get to read the BOM of the source files via Inventor’s Bill Of Materials dialog. Check out this video to see how it’s done:

Does it work?

I’ve only been able to test it using datasets created in Solidworks 2015 SP1.1. So I can’t speak for the other file formats at this stage, but the harsh reality is there are issues. Bearing in mind that there is a lot of Black Magic going on here, it is hardly surprising. However, this is the first release of the technology and I have no doubt that PTC’s Unite Technology will have issues as well. But the great thing is, both of these companies are having a go at breaking down the barriers put up by competing CAD file formats.

The problems I have encountered initially are:

  • 80% of the time a projected edge from a Multi-CAD source will fail on update when the source model geometry around it changes.
  • Geometry changes within the boundary of the Multi-CAD model work better than changes which result in the overall model size changing.
  • Assembly Joints & Constraints are a bit hit & miss at release, but those relationships are more stable than sketch projections are.

So basically, if you stick to a bottom > up modelling workflow with these components you are more likely to succeed than using a top > down approach.

I did manage to program a native Solidworks part file, inside Inventor HSM though and maintain an associative relationship:

DWG Underlay

Another excellent feature which arrives under the ‘Multi-CAD’ banner, is the AutoCAD DWG Underlay. I was honestly speechless when I saw this for the first time. Having worked with Inventor in the Super Yacht interiors industry for 10 years, I’m acutely aware of how poorly Inventor handles large amounts of AutoCAD 2D objects. General Arrangement plans are highly detailed beasts in the marine (and aerospace) industry, because they’ve historically been used to sell yachts there is a lot of stylized line work. It can be a pain to clean it all up, only to receive another version the following week. God I wish I had this tool in the past. Feast your eyes on this:

* Digging through the Autodesk Inventor Trademarks and credits declaration, you will find a reference to CADCAM-E.COM. Credit to a very curious colleague of mine for finding that!

A Story Of Implementation – The Path to ERP

What’s the first step towards selecting an Enterprise Resource Planning Solution? Knowing you need an ERP system! Before choosing an ERP system evaluate your business first. Where do you excel? Where are you inefficient? Where do you want to be be in 3, 5, or 10 years? Once you have answered these questions you’ll be better prepared to make your selection. Continue Reading

Join the Community