Software Meeting

Every component manufacturer should hold a ‘software meeting’ as a regularly scheduled event. The software meeting is a recognition of the importance of design and management software to the organization and a proactive attempt to use that software to gain the fullest advantage for the organization.

Why hold a software meeting?

The software that plays such a significant role in our businesses is complex and ever-changing. How do take maximum advantage? We have to invest time as a company to review all aspects of our software use. What’s new in the latest release? Should we be using it? How does it work? What problems do we have? What do we most need that we don’t have? These are all questions that are best answered in a group setting, with everyone participating and contributing – even the boss!

How often?

At least once every quarter, but it also makes sense to hold one every time a software release is announced. For MiTek customers this means five time a year. This may seem like a lot, but the features and fixes are coming fast, and the only way to stay on top is to have frequent group reviews.

Proposed Software Meeting Agenda

This meeting, like all meetings in the organization, needs to be time-boxed and laser-focused.

Feature Review – Two weeks prior to the meeting the design manager reviews the latest Release Notes and assigns one (or more) new features to each designer to research. Each designer comes prepared to show the feature, describe what its intended uses are, and offer an opinion as to its value to the organization.  A general discussion then decides if the organization is going to begin using the new features and what steps are needed to implement it. The group should be mindful of how to use the feature to the organization’s best advantage and how to do so consistently. This means everyone is on board, doing things in the same way so as to deliver a consistent product to customers.

Problem Review – What’s slowing me down or holding me back? What’s annoying me? What do I wish I could do that I can’t now? Every designer and software user should be called on to contribute. The group should attempt to expose as many of these problems as possible, Having participated in many software discussion like this, you can expect that between 25% and 50% of the problem raised will be solved by other software users who have simply learned (better) how the software works, or developed tricks or workarounds that take much of the sting out of the problem. The others should be noted on a “Problem List” that is then forwarded to the software rep.

Idea Time – What could really make us more productive? What would we like to know that we don’t know now? What part of my job would I most like to unload, and why? These type of questions frequently touch on both software and business processes and the Software Meeting is a good time to talk about improvements in both. It is essential that managers participate and talk about the information that they need to allow them to manage better. Every organization could improve if it knew more about itself, particularly about performance. Can we get that data? How? Again, a software wish list may be the result – a list that should be shared with the software rep. Alternatively, why not invite the rep to the meeting?

The software being discussed should ‘cover the field;’ it should not be restricted to one vendor. In many companies the ERP software plays a key role, in others, several different vendors provide design and estimating software. Its best to look at the overall picture to look for duplication of effort or discovering ways to integrate the different solutions.

What Can Be Done With Plates

When I taught a class called “Advanced Features of MiTek Software,” one of the modules reviewed all the things you can do with plating. I found then and still find today that customers don’t always realize how much control they have. What we’ll cover here will be some basics – we won’t attempt to do training and we won’t attempt to get into the nitty-gritty engineering stuff either. I want to cover the basics of “what’s out there” so you get a sense of some of the things you can do.

Multiple Plate Inventories

Most plants use a single inventory that includes all the plates are usually stocked. But you don’t have to limit yourself – you can be more creative than that. There is a “All Available MiTek Plates” inventory that ships with the software. That comes in handy if you have a particularly difficult plating situation and just want to see if ‘any plate known to man’ will work. You can, if you wish, create a separate inventory for roof trusses and floor trusses. This is especially easy to do as the program allows a place for a separate inventory for roof trusses and floor trusses – most plants simply plug the same one in for both. You can actually set up any special inventory you want, and then apply it on a job by job or a truss by truss basis.

Temporarily Out of Stock

When you run out of a plate, you can simply uncheck it in the master plate list (which shows all plates in all inventories.) This takes it temporarily out of consideration from any inventory that the plate is part of. When you get your next shipment, simply “recheck” the plate to reinstate it.

Controlling Minimum Plate Sizes

When the MiTek program begins to analyze for plating, it identifies each joint by the combination of members coming into is. Knowing the joint type (visible in Plate Editor) allows you to modify the minimum, plate sizes to your own standards. For example, a peak plate for a Fink truss with 2x4 chords is a C-C-W-W and minimum sizes can be set for different span ranges. Different plate minimums are also associated with different chord sizes. Setting plate minimum sizes to what your shop actually uses is beneficial both in correctly costing the truss and in making sure that the sealed drawing matches the built truss – which can help a lot if the building inspector is taking a close look at things.

Controlling the Plate Orientation

Ever see a plate rotated a certain way and wonder - “Why?” Each joint type has a ranked list of “acceptable” orientations. The program tries the smallest plate in the first orientation, and if that fails it tries each of the other orientations in order. If they all fail, the next plate size is tried and this continues until the joint plates. By changing the order of the ‘preferred’ orientations, you can almost always have the program orient the plates they way you want without having to resort to Plate Editor.

Centering of Plates

Several settings work in concert to make plate fall in the “center” of the joint. This is done because it is considered more likely that a production worker will place a centered plate correctly than an “non-centered plate.” But is this still the right way to go when the production worker has the benefit of lasers to help him place the plate correctly? Reduce the “Sq. in. saved before using non-centered plates” in Plate Options to reduce the upsizing of plates done to locate them at the center of the joint.

Last Resort Options

If you have one of those trusses that is just hard to get to plate, remember this trio of Plate Options may at least help you get to the next step: “Plate even if overstressed” allows the plating routine to go forward, even if the truss fails. “Allow overlapping plates” will at least see if the program can find a solution – even if the plates are overlapping. “Allow perimeter violations” allows you to see how close you are to getting a plate to work without plating outside of the perimeter of the truss. With each of these situations, good judgment and close consultation with your ‘review and seal’ engineer is essential.

Grading Software Features

“Features” are simply the "things we can do" with a given piece of software. Component design and production software now possesses an overwhelming number of them; so many in fact that rather than being excited about new ones, many software users carry around a sense of permanent guilt - fueled by that gnawing feeling that they only know about a fraction of what the software can do. New releases just add fuel to the fire.

It's fair to say that as a software community we haven't figured out yet the best way to keep up to speed on all the things that the software we use can do. Some form of continuing education is no doubt needed. The suppliers, still in transition from an era where most of the training needs were for new users, have created a lot of training content but have not figured out the best way to package that content so it is easily digestible. Software users on the other hand frequently pay lip service to learning more about the software, but when opportunities are presented, many frequently don't take the time to take advantage of those opportunities. Sounds like a good subject for a future article.

Back the features themselves. Here is a suggested method for evaluating them.

Utilitarian

A feature usually can be classified either as "I can use that," or "I have no use for that." If a feature appears to have no useful value to you, it's a good idea to ask the person showing you the feature or a representative of the supplier, "Can you think of the way that this feature might be useful to me?" This is a good double check, to make sure the feature has no practical value to you. Asking this question also tests the recipient -- their answer will demonstrate how well they understand what the feature does.

Implementation

Elegant – The feature is surprisingly easy to use. It requires no instruction, except on the finer points.

Okay - The feature is certainly usable, although there are obvious things that could've been done better.

Lacking - Perhaps the supplier had the best of intentions, but the implementation fails to hit the mark. Significant desirable functionality is missing, and/or the user interface is confusing or awkward.

Accessibility of Features

Recently I’ve realized how important this is to the true value of a feature. Evaluating the customizability of a feature is often overlooked because we generally assume when a feature is introduced that anyone will be able to use it - and customize it. It's pretty obvious that a feature is much more valuable if I can customize it, vs. having to call someone and ask them to do it for me.

Grade A - Any sharp, computer savvy user can make a feature do what he wants. Many times This is dependent on the elegance of the implementation of the feature. Did the software team really spend a lot of time thinking about how the user would configure the feature? If they did, the feature usually ends up with an “A” in this evaluation.

Grade B - Many, if not all, technical support representatives can customize the feature. Customization can usually be implemented within a day. Many powerful features such as the batch cutting routines require a considerable amount of knowledge and experience to implement them quickly. As long as the technician is readily available, these skilled at the listening the needs, and is able to turn around the request quickly, the feature will be readily embraced.

Grade C - A small number of technical support representatives can customize the feature. The feature is either so complex, so new, or so poorly implemented that only a few technical support representatives have mastered it. Reaching the right person is usually the biggest difficulty. Turnaround time to customize the feature is usually measured in days.

Grade D - Any customization must be done by a programmer. The customization is treated internally as a programming project, with all the delay in bureaucracy that that entails. The user may need to wait weeks or months in order to get the customization. The feature ultimately gets an “F” in this evaluation if, from a practical standpoint, the user can't get the customization no matter how long he waits.

In evaluating any feature make sure you think about how it’s customized. Some features appear to be very exciting, opening up rich new areas of functionality. For each of these features it's worth exploring the question, "Who does the customization?" The answer may have a tremendous impact on the usability of the feature.