Deploying DriveWorks Throughout the Organization

Editor's Notes

• #2: Good morning, folks.
• #3: So before you start pulling out your notepads and scribbling furiously, I will let you know that the full presentation will be made available on the Razorleaf website shortly after this DriveWorks World conference. You will notice, however, that the slides themselves do not contain all of the content that I will be providing. All of the text that I was supposed to remember to say is contained in the presenter’s notes. So be sure to look down there. The purpose of both providing the presentation and not cramming the slides full of choice words is to encourage you to focus on the topic at hand and not miss another important point as you feverishly strain to write down a first very important point. And yes, the presenter’s notes even contain some of my ridiculous little attempts at humor. That is, those that don’t just slip out as I go along.
• #4: Just a very quick rundown of Razorleaf so that I can justify my expenses to get out here…Razorleaf is an Authorized and Certified DriveWorks Services Partner. 2015 marks ten years that we have been providing implementation, training, support and integration services for DriveWorks. We work with our DriveWorks reseller partners as well as with clients directly to get you started, fill in when you need extra DriveWorks bandwidth, and to help you through when the going gets tough. We have other groups within our company that serve other engineering and enterprise technologies from PLM to SharePoint. We handle the nation’s automations, implementations, integrations, migrations, configurations, educations, optimizations, and customizations so you can get your ISO and government certifications. Me? SolidWorks, DriveWorks and design automation is pretty much all I’ve been doing all day every day since the beginning of time.
• #5: Just a quick overview of the alleged wisdom that I’m here to impart to you today. The topic of Deploying DriveWorks Throughout the Organization can refer to how to roll out your implementation or a discussion on where else in the organization DriveWorks can provide benefit. I’m going to attempt to touch on both in a scant 40 minutes. Anyone that’s received an email from me or has seen my posts on the forum knows that I can’t even keep my opening paragraphs under 40 minutes, so we’ll see how that goes. If there’s something that you’re interested in that I don’t get to, feel free to corner me and I’ll be happy to discuss it with you.
• #6: DriveWorks has always been known as the way to make SolidWorks models and drawings faster and with no work from us in Engineering. And that’s great. DriveWorks is typically brought in as an Engineering tool and people try to justify it by how much time it will save in Engineering, turning that into a dollar value. But can you really pay for DriveWorks that way? Well, actually, yes. You can pretty easily. But we’ve found that once we look at where Engineering fits into the larger process, we can find even more benefits throughout the organization, up and down the process flow.
• #7: Before you can implement any technology into your process, especially going across groups within the organization, you need to understand your process. To me, it’s all about the process. Yes, that is, in fact, my real title. Mapping and designing your process is critically important, but that’s another discussion altogether. You can look up presentations that I’ve done on this topic for SolidWorks World and elsewhere on the Razorleaf web site or slideshare.net. The important point is that DriveWorks can have an impact upstream and downstream of Engineering. But to see where it can fit and how it can help the other players in the process, you have to get a better handle on what everyone else does and how it all fits together. Where is the information that you generate in Engineering consumed? Where does the information that you need in Engineering come from?
• #8: Let’s take a look at some of those groups and some of the ways that we’ve found to extend the benefits of DriveWorks throughout the enterprise.
• #9: Looking up and down the process, the first place that we can start expanding from Engineering is reconsidering the information that we have DriveWorks generate from our Engineering data. Generating drawings for production is one of the tasks that DriveWorks can do better than just about anyone. If you consider, though, what happens to those drawings once they’re created, you can often find more opportunities for DriveWorks to save time and money while boosting quality and reliability. We have worked with several companies down in the southeast and across Texas that make extensive use of standard extruded shapes. The machining that was done to the extrusions was minimal, just drilling holes at specific locations for hardware. Special drill presses had been set up to make the drilling of these holes in the extrusions faster and easier. The machinist only needed to know which extrusion to grab, which hole diameter and the location of the holes. Not only are we wasting time and trees creating these drawing views, but now we’re requiring our machinists to read drawings. It may not seem like a big deal, but that is one more place for something to go wrong, and it means that we’re increasing the qualifications that we need out in the shop. Most ERP, MRP or MES systems will generate routing sheets that provide the person at the workstation just the information that they need. DriveWorks knows this information, why make it more complicated than it needs to be? We can generate that very easily in DriveWorks. Yes, even the bar code. The only challenge might be finding green bar paper and dot matrix ribbons at your local Staples.
• #10: Another example of this disconnect happened at Bailey International in Tennessee. While planning the implementation, in particular the drawing outputs, we decided to bring the shop into the discussions. We had built some mock-ups of the new drawing formats and we walked the floor. We talked to the folks at the machines, not just the shop foreman. What we found out, and were able to fix thanks to DriveWorks is that the people in the shop were spending an inordinate amount of time searching for the information that they needed. Every drafter created drawings with their own signature flair (+5 style points for DriveWorks being consistent) which made the machinists hunt around for the dimensions and often, the dimensions that were actually needed for manufacture weren’t there and required a calculator. Since the specification knows everything about the design, we simply let DriveWorks put the information that the shop people need in a very clear, very concise, very consistent table in the corner of the drawing. <CLICK> DriveWorks had no trouble at all compiling the information and driving the drawings. And the shop folks went to the same place, every time for exactly the information that they needed, in the format that they wanted. Almost overnight, shop productivity shot up, delivery times dropped, and scrap all but disappeared. Now this engineering tool was being used for saving money in the shop.
• #11: Looking further UP in the process, we can look at where we get the information to feed our Engineering tool. DriveWorks saves us time in Engineering, and that’s great, but you can’t save yourself into being a millionaire. If you want to make more money, you have to bring in more money. DriveWorks saves our Engineers sanity (assuming we still have any left) by making the salespeople self-reliant. OK, well, less reliant on us. Without waiting on Engineering and taking up engineering time, they can get out more, better quality quotes, faster. And since as DriveWorks administrators, we took our time and carefully crafted those quotes in DriveWorks, they’re more complete, more consistent, more professional, more accurate and more competitively priced (while still preserving our margins) because we can now calculate precise costing. The law of averages says that more (and better) quotes means more business which means more money which means huge bonuses for the engineers. OK, well maybe all except that last part. But the point is that the company is making more money while the engineers are making more new products. Quite simply, expanding the tools that we developed in DriveWorks and using them further upstream makes DriveWorks exponentially more valuable.
• #12: The point of DriveWorks forms is to collect complete, accurate, and manufacturable information. Even if we don’t have DriveWorks create any sales deliverables, just having forms for Sales or the prospect to fill out can be a huge benefit. Now I’m sure that this never happens where you work, but when I worked in an Engineering dungeon, I mean, department, we would get requests from sales on everything from Post-It notes to remarkably short emails to casual comments while we were walking to the rest room. It always amazed me that our salespeople would talk for hours on end every time they could corner us, except when it came to giving us the information that we need. Again, I’m sure that this never happens where you work, but a lot of our Razorleaf clients also reported the experience of having to go back to the salesperson, or worse, the customer and say, “Um, yeah, we really don’t know what we’re doing. We forgot to ask you …” This does a lot to destroy the prospect’s confidence in us, drag out the sales process and create the greatest anxiety that you can in an engineer, namely, requiring us to interact with other humans. Never happens, right? Just like our salespeople never sell something that just can’t be made. “Oh, they need a 240 horsepower computer fan, do they? Yeah, let me go find one for you.” Sometimes, in the past, we’ve built forms for our salespeople. Paper forms. Excel sheets. And that’s helped a little. But you can’t stop them from putting a checkmark in the DIAMETER field. But DriveWorks can! Complete, accurate, manufacturable information. Every time. Then we have that information in DriveWorks that we can use for steps further down our specification flow.
• #13: Let’s switch over to the unicorns and rainbows of the world of marketing. Every marketing group is looking for something that they can use to give them an edge over the competition. Some will use the sheer fact that DriveWorks gives your company the capability to offer customized products at standard product prices, while the competition will only sell from their catalog items. Others will tout the DriveWorks 3D Preview that allows prospects to view their product before they order. But in a lot of cases, marketing groups will want images or outputs for products that don’t exist. In some cases, they want LOTS of images to fill catalogs or create web sites or whatever it is that marketing people do all day. We have worked with companies to mass generate large amounts of project configurations utilizing DriveWorks AutoPilot. Depending upon the circumstances, there were a few different approaches that we took. In one case, the configurations varied so widely, that the company sat down and built an Excel workbook with all of the inputs. We then converted that spreadsheet into an XML and utilized the IMPORT SPECIFICATIONS button in DriveWorks Autopilot to create almost 100 specifications from the XML with just a few mouse clicks. In another case, there was also a spreadsheet involved, but this one was a matrix and the only input was a product code which we could use to decode the inputs. In this case, we simply copied the spreadsheet into a DriveWorks Group table and utilized Specification Macros to walk through the spreadsheet and generate models and drawings. Here, we didn’t worry about creating separate specifications as that was not important. A simple RELEASE MODELS task in the specification macro would send our models and drawings to the queue and then move onto the next one. Another very similar case did not use a table, but this time, the inputs were regular enough that we could simply loop through the values. Again, some fairly simple DriveWorks Specification macros were used to get it done in a hurry. The important point here is that no code was used. All standard DriveWorks functionality.
• #14: Here’s another interesting marketing application that we came up with. Since enterprise implementations of DriveWorks are primarily used on the web, and since advertising on web pages and in apps has become so ubiquitous that people simply accept and expect it, then why not advertise within your DriveWorks implementation? Now I’m not saying that you finance your DriveWorks implementation by selling pop-ups for Candy Crush, but based on the selections that the user is making, intelligent and targeted messaging can be presented in a fairly subtle fashion, letting your clients know about other features, products, or specials that they may not be aware of. This can be as simple as highlighting all of the possible options on your product to solicit an “oh, I didn’t know that was available” response, to even adding a banner-style frame at the bottom of your forms or an Amazon-esque “People who selected that option also selected…”.
• #15: Another truth that we’ve found to be self-evident is that the information that DriveWorks generates is useful in so many areas across the organization, even after the specification is completed. Many of our clients have us set up DriveWorks to export information that their sales department uses to report on quoting and order statistics. Others have us write out BOM information for procurement or scheduling information, and so on. By simply exporting information to a SQL or OLE data source or via XML, we can make that data available to a variety of systems for materials management, procurement, scheduling, inventory, and on and on. Can DriveWorks then act as a sales management system, generating dashboards and reports for sales managers to see how many quotes have been created, what products were quoted, for how much, and so on? Certainly, it can. You need to be careful, though, not to spend your time rebuilding existing tools inside of DriveWorks. Most companies already use a CRM or Sales Force Automation system that already has those capabilities.
• #16: But the flip side is also true. Our users and other systems can generate information that DriveWorks is better suited to work with. Material pricing and availability, contact and customer information, and more can typically be made available quite easily. Situations exist rather frequently when you may want visibility to that information to make decisions during your specification. A tool that we built for a company down near St. Louis determines the number of pallets required, then checks multiple shipping methods to determine the fastest and cheapest way to ship the product. Or you may want to report on this information and act by opening a separate DriveWorks project right from there. We’ve used the Create Closed Child Specification tasks not only for creating branches on wire harnesses or nozzles and flanges on pressure vessels, but also to have DriveWorks run a reporting tool that we created as a separate project and return the information that we need. Since this is a separate project, it’s available to all of our product lines. In these cases, DriveWorks is a perfectly capable tool for doing this. Glen will be going over integration with 3rd party products tomorrow, so I won’t go into the details, but we can’t stress enough how the information that DriveWorks has and needs for each specification can be available upstream and reusable downstream by other systems.
• #17: But once we start talking about SQL certain uncomfortable parts of everyone’s anatomy starts to pucker up. “Wait, now you’re talking about hiring DBAs or integration consultants or, heaven forbid, letting MY people use THAT!!!!” Relax. Seriously. SQL Manglement studio is very intimidating. I’ll give you that. But you can use other tools to work with SQL including Excel, Access and…TA-DA!...DriveWorks.
• #18: So what a lot of people don’t realize is that when it comes to the maintenance of this data, we can leverage DriveWorks even more to take that burden off of the administrators of the DriveWorks implementation. We have set up many projects that empower other internal resources, and even the end customer, to build and maintain this information. One client in Rhode Island has a collection of integrated circuit sockets that grows daily (the collection grows, not the sockets). Before DriveWorks, they managed all of this information in a massive Excel spreadsheet and separately, the images and pin files to go along with each socket. We built a very simple project that allows multiple users to enter the details of the socket into a nice little DriveWorks form and to upload the image and text files using upload controls. DriveWorks ensures that the information is complete, then makes sure that the tables are filled in correctly and the files are put in the proper locations with the appropriate names. Using Group tables (as we did in this example) or external SQL databases (as we have in many others), this information is available to any project in your group. With basic DriveWorks forms, built the way that we teach in training, your controls will be updated automatically. All lookups, queries, table functions, all reference the latest and greatest information with no DriveWorks Administrator intervention required.
• #19: Probably the most underused functionality is one that we use in every implementation, the DriveWorks tech folks hold countless webinars on and Phil just spent his time talking to you about. With the capabilities that you just saw in Phil’s talk, you can see how DriveWorks is easily extensible throughout the kingdom of your company. Approval processes for engineering changes or drawing releases are so common in PDM and PLM. There is no reason why that approach shouldn’t apply to the areas that your DriveWorks implementations address. When designing specification flows that go across departments, you get to consider who should have visibility to what, and when. Here is an example of a specification flow that we developed to take advantage of the Triggered Actions added in DriveWorks 11. People outside of engineering needed to know when SolidWorks models or drawings had been created, and in turn, DriveWorks needed to know when the ERP information had been generated. Triggered actions do nothing more than watch for the existence of a file. It doesn’t matter if DriveWorks is creating that file or if another system is generating it. Once that file exists, DriveWorks will act, transitioning on to the next state. In this example, we had a custom specification task that would retrieve a custom property from a file. When tied to a triggered action, this would allow DriveWorks to analyze the results of the model generation and look at, in this example, the weight and a reference dimension value from the SolidWorks model and determine which path this specification should follow. At one point, we even created a self-running loop that worked in a manner similar to SolidWorks Simulation’s OPTIMIZE, running through multiple scenarios until the criteria were met.
• #20: So we recognize that there are other areas in the company that can benefit, so let’s start to look at what you can do to really screw that up.
• #21: My engineer clients all say the same thing, “I know our process.” You know what your process is supposed to be and how it’s supposed to work. As much as we, the anti-social engineers, would like to believe it isn’t true, the first thing that we need to do is to actually talk to these people. And by these, we mean the stakeholders AND the users. In the vast majority of our implementations, the information that we get from managers and supervisors does not match what the folks that actually do the work tell us. That is why we speak to them separately, then together. It is up to you to find out AND DOCUMENT the process: what information each player knows at each stage in the process, what information is needed by their customers (whether that’s within the company or outside), and what form that information should take, pronounced “outputs.”
• #22: The number one cause of failure in any technical implementation is a lack of user acceptance. No matter how magnificently elegant and powerful our tool is, if they won’t use it, it will fail. We have to remember when we are taking DriveWorks outside of Engineering, that others may not be quite as open to new tools and new technologies as we are. Let’s face it. They still have flip phones. By including these people in the process and leveraging the methods and knowledge that they have developed over the years, they will be more accepting. You are telling them that we are going to change how they work every day. That’s going to rub some people the wrong way and scare others. You can ease people’s fear of the new by creating User eXperiences that feel and look familiar, leveraging the processes that these users have developed over the years and creating the outputs that they have grown to expect (along with newer ones). Gradually, we can transition them over to something closer to our vision, but we have to get everyone on board and up the learning curve first.
• #23: CRITICAL to every implementation, right up front, has got to be Use Cases. This is basically a set of specifications with an answer key. “If I select A, B, and C, my output will look like this.” This is important for two reasons. First, you need to have tests to run. Every small section from how the UI reacts to what a variable value should be to what your SolidWorks models and drawings should look like should be tested with agreed upon and DOCUMENTED cases. This is not a matter of “oh, he’s pushing official protocols.” This is a matter of you need people to agree what the answer should be. One client in California repeatedly told us, “This is what that unit should look like” only to find out that every time that it went out to the shop, the shop would “correct” it without telling anybody. We spent far too much time just getting them to reconcile the results with the shop, including running physical sheetmetal tests. The other part of this is that there are most likely an infinite number of combinations and permutations that your DriveWorks implementation is going to support. Are you going to test them all? You need to intelligently develop a minimal group of cases that will test the extents of each option in your implementation. A long unit, a short unit. One with miters, one with a notched joint. One that exceeds this threshold and one that falls below it. Take your time and develop these use cases as a group, carefully and intelligently. When, and only when, all of your use cases run flawlessly, then you can roll out to your user base.
• #24: User eXperience design is something that we at Razorleaf are asked to often. What we stress and what is most important to understand is that you have three goals with a UX outside of Engineering: 1) Collect complete, accurate, manufacturable information, but that’s only one of the three. The second is to make sure that the user has a 100% unambiguous understanding of what it is that they’re getting and that they can review it and agree to it. And finally, this is your chance to convince that customer that you are easy to work with. If it’s an internal customer, that will encourage them to use the system and not bother you rather than going around the system, “I didn’t have time to put this in, can you just handle it for me? MM, yeah, thanks.” And if it’s an external client, it will make them want to buy from you. So here are the best ways to ruin that. Make it confusing or tedious for them to give you the information. Put your controls all over the place, make the flow of the form bounce around like a racquetball, give them blank fields where they have no idea what information they’re supposed to provide and give them errors or fields that are greyed out without telling them why. In most cases, they aren’t experts in your product like you are. You can use technical jargon and require information that they will never in a million years know to drive them crazy and drive them away from the site. Another great way to make your forms fail is to make them go on forever. You can do that by cramming a bazillion fields onto one form or by having more forms than any human could possibly sit through. It’s like those surveys that you fill out to try to win the $4 gift card. After a few pages you’re thinking, “OK, how long is this?” After a few more, “Really? Come on now.” After a few more, “Forget it. I’m not going to shop there anymore anyway.” <CLOSE>
• #25: And it’s not just about the look and feel of the UX, but it’s about its content, as well. The User eXperience that we’re after is what I like to call Guided Selling. You’re walking them through your product and how to create one. You’re asking them about what they need. One of the biggest mistakes that our clients make trying to move their DriveWorks tools out of engineering is that they think that the users will know the input values that DriveWorks requires. Project Tables, Group Tables, Query Data, logic functions, calculation functions, they’re all in there because the information that we know is typically not the information that needs to go to SolidWorks or to Excel or to our ERP system. Whether it’s a calculated performance characteristic of the custom unit, a member profile that is dictated by ASME code or some other guideline, or a critical mounting or envelope measurement, all of these values are determined by the selections of the user, they are not inputs from the user. You may be able to determine these values, maybe off the top of your head, but you need to find out if your users will know, or even care about these values. If not, then they are variables, not form controls. And you need to learn how to get from what they know to what you need to know. The UX collects what the user knows, not what you need.
• #26: But the best way to fail, or at a bare minimum, to make your life a living hell, is to not test enough. The longer you go without testing, the more you will have to test and harder it is going to be to find what went awry. And let’s face it. Every week has a Monday in it. Something is going to go wrong. But before you can even test, you have to have something to test with. That’s where those use cases come in. You need to have set inputs to test with and known outputs. For every project that we start, we not only collect and document the use cases, but we create XML files with the inputs. This allows us to use Autopilot and its Import Specifications that we spoke about earlier. (Well, that I spoke about and you almost stayed awake for.) Every time that we add new functionality, we fire up Autopilot, with a few clicks, we run our tests and we validate. Having it be that easy to test makes it easier to test frequently. Each time you add functionality, test it immediately. And test to make sure that nothing else was affected. Test your UX, making sure that anything dynamic works properly. Controls move properly, images change, min/max values update, errors are shown at the appropriate times. And bring in a few of the users that are going to be using the system to help you with this. You can get feedback from them early to avoid any backlash and help ease them into using it. And once it does pass all of your use cases, then bring in a few adventurous, patient users to try it out. Make sure that they understand that it’s not released yet and if something happens, don’t panic, you’re there to fix it. Releasing anything that has even the smallest problem is a sure way to start a mutiny against your tool. “Oh, this thing is a piece of garbage. It doesn’t even work!” “All that’s happening is that it’s turning red instead of green.” “See! It doesn’t work! Useless!” And once all of that pans out, then you can move to release it. But yes, you want to test it one more time when you get it on the production hardware. Why? Because doing the same thing over and over again and expecting different results is the definition of Microsoft Windows.
• #27: So if we really want to screw up a DriveWorks implementation, all we have to do is to build it our way. We know how Sales and the shop are supposed to work. We’ve been here long enough. They’re going to get all of the information that we want to give them in a format that is perfect for what WE are trying to do. Then just throw it at them and tell them that they have to do it this way from now on. No, really, they’ll love you for it. They will be so thankful that you are showing them a smarter way to work. And don’t bother trying to figure out what it’s supposed to do and what is supposed to come out. We can just click a few times when we’re done to show that it works. We grew up with 40 worksheet Excel workbooks to do calculations, your DriveWorks User eXperience should be just as good. Make it convoluted and make it go on forever, and make it so hard to figure out that they will come to you constantly for the first few days to ask questions before they just give up entirely. And let’s keep it technical. Use terminology that is not only highly industry-specific, but is based on inside jokes with other engineers. Stuff so technical that even you don’t get it. And make sure that you require information that they will never know. And if they try to skip it or type in something random, have it cancel out. Then, once you’re done, just throw it out there. They’ll let you know if something is wrong. And they’ll still be so grateful for you showing them the light that it won’t even bother them. And if they do yell at you to make sure that it works, just click a few random buttons and that should be good enough.
• #28: And that’s all you need to know. It’s just…that…easy. If I have time, I’ll be happy to answer questions. And even if I’m not happy to do it, I’ll probably do it anyway. But if we don’t have time, or if you’re a fellow engineer that really doesn’t want to talk in front of everyone, I feel you. You can catch up with me over the next couple of days. And if you want more detailed information about Razorleaf, I can give you my boss’ home and cell phone numbers. Thanks!