|
For many years now, AVAware has seen distributors and manufacturers alike struggling to implement every manner of ERP and inventory management solution, ranging from the "quick and cheap" to solutions costing tens of thousands of dollars. Although some have been able to coax limited functionality after seemingly endless development initiatives and ever-increasing project budgets - all of them inevitably ask the same question: "Why does it seem like something that every other industry in the world is able to implement routinely, is such a challenge in the world of architectural hardware?"
In reality, it doesn't just "seem" like a challenge… It absolutely is. Architectural hardware presents a number of challenges that make its products, and their management, distinctly different from nearly every other industry on earth. It's a difficult concept to wrap one's head around - let alone fully believe - that a lockset or a closer can be that much different from a hammer or a power drill. Make no mistake about it, they most certainly are. There are a number of key considerations that manufacturers and vendors of architectural hardware have to contend with that not only make this narrow vertical market distinct, but a nearly impossible challenge for conventional management techniques and software.
The most obvious (and problematic) issue is that of product variation. In an article discussing AVAware's catalog technology, a mathematical analysis of a common product catalog was described. After calculating all the combinations and permutations available given the options available for each products (function), it was determined that it was possible to order over 100000000 unique product variations from that one catalog alone!
This was done in order to demonstrate why a conventional "product listing" that satisfies the needs of so many manufacturers is simply not viable for many of the product lines in the world of architectural hardware. Even if one were to go through the machinations of "pre-building" every possible product variation a catalog can offer, each one would have to be re-priced each time a new catalog or even a catalog update is released. This argument is entirely academic, since it's also entirely impractical to even consider maintaining products lists consisting of millions upon millions of unique items for every product line. This was the reason that AVAware's product catalogs were designed to enable users to "build" products based upon available product options on "as needed" basis.
Product Nomenclature vs. SKU Numbers and Field-Length Limitations
A major implication stemming from the massive number of product variation is the inability for manufacturers to use conventional product codes or "SKU" numbers that so many conventional software packages rely on. ("SKU" is an acronym for "stock control unit"; somebody obviously took some liberties with the spelling!) Instead of a short string of numbers, products are identified by a nomenclature string that is built-up using codes and abbreviations for the many options given for a particular product. Depending on the product in question, these nomenclature strings can get very long; some even surpassing 50 characters. Over and above the obvious challenges this raises in the areas of convenience and accuracy, it creates an even larger issue for many software programs that are built with 20-25 character (or less) limits on product codes. These limits were imposed by software designers that were anticipating traditional SKU numbers - not the byzantine codes that are prevalent in many architectural hardware catalogs.
If the computers didn't present enough challenges, humans naturally had to make their contribution to this debacle. Although most catalogs describe a "standard" format for building that string, many detailers and estimators have chosen to evolve their own variations on those standards - just to add their own special touch to an already confusing situation!
| 
|
| Product Matching for Inventory Purposes
Although it's true that many products (locksets for example), have thousands upon thousands of product variations, that doesn't necessarily mean that each one represents a different box on the shelf. Often times a single item (box) can satisfy many different product variations. This is due to interchangeable components and options that can be "field modified". A common example of this is handing; many lockets can be switched from left to right handed by the installer - while others need to be ordered for the specific handing required. Since this feature varies from product to product, it presents another challenge for inventory management and ordering software: Can a left-handed 'lockset L1" be used to fill an order for a right-handed "lockset L1"? Door closers offer another common example. While many closers can be ordered with different arm options (i.e.: regular or parallel), many are also packaged with several arms together in the same box. Therefore, several different product variations (and product codes) can be satisfied by the same item. Once again, this varies from product to product and manufacturer to manufacturer. The process of determining whether two different product codes actually refer to two different products is referred to as "product matching". Bear in mind, this is not as simple as identifying two codes as being "the same". In the case of closer, for example, each arm option comes in thousands of its own variations based on the number of product options available. As such, the process of "product differentiation" involves co-relating thousands of product variants to a single box on the shelf.
|
The Need to "Mix and Match"
Many of the components that make up or ship with architectural hardware products are designed to be interchangeable. Items such as roses and trims and be easily swapped from one lockset in a product series to another. In order to fill customer orders or to replace lost or damaged parts, distributors often pillage inventory stock for those needed items. In addition, often times multiple products are taken from the shelf and combined to create a required configuration. While an individual with product knowledge may realize that a product order can be filled by combining existing inventory product with the addition of some low-cost components, no inventory control software would be capable of making that determination - unless it were equipped with sophisticated software, programmed with construction details for every product.
Whether it be a result of laziness or a reluctance to "write off" an entire product because of a few parts that have been removed, the resultant product carcasses are left remaining in inventory. This creates a variety of issues from erroneous valuations to short orders due to products that assumed (erroneously) to be in stock.
The long and short of it all is simply this: architectural products are complicated. They cannot be treated like "widgets", in the traditional model used to teach and implement conventional inventory management systems. Clearly, something far more sophisticated, and purpose-designed, is called for.
Manufacturers' Solutions
The difficulties presented by architectural hardware products become apparent in many applications, not the least of which is positioning them into retail environments. All retailers, particularly those of the "big box" variety, require manufacturers to provide conventional product listings - with those pesky SKU numbers. For this reason, many manufacturers have taken small selections of commonly used products in their most typical variations and created lists of items often referred to a "quick ship" or similar designations. These "quick ship" items are pre-selected product configurations that are offered for sale to retailers and distributors, and can be ordered (and managed) using conventional SKU numbers. The moment, however, the slightest change is required to even a single option, it must be ordered using its traditional nomenclature string and is considered by retailers to be a "custom" order.
Conventional Software Solutions
Many software vendors have approached these various challenges; at AVAware we’ve have seen many over the years. Notwithstanding some limited successes, most have fallen disappointingly short.
The most ambitious ones, perhaps because they haven't done the math or perhaps because they don't understand the multiplicity of combinations and permutations, endeavour to create "flat" lists of pre-built products. Some are even foolhardy enough to believe they can pre-build every single possible product variation that each manufacturer offers. AVAware has received numerous requests from brave souls such as these to "pre-build and export" every single product variation in existence. Needless to say, we had to disappoint them and explain the folly of their plans. Quite frankly, even if the product variations were limited and one could pre-build each one, someone would have to manually re-price every one of those variations each time the manufacturer updates their catalog. In some cases, that task alone would take longer than the period of time the price book is even in effect!
AVAware's Solutions
After years of studying this situation and discussing needs and options with our clients, AVAware's development team set out to create a solution that would address the challenges presented by architectural hardware along with all their nuances. From the creation of AVAcad and the often-copied Openings Schedule model, AVAware's industry solutions are some of the most thoughtfully designed and technically advanced software packages available. AVAware's product catalogs are still the only ones ever created that include manufacturer-specific software (created using a proprietary scripting language) that are capable of automatically pricing even the most complicated products. If AVAware was going to offer an inventory solution, it was going to be a good one; needless to say, the developers really rolled up their sleeves for this particular list of challenges!
Building upon the power and flexibility offered by catalog technologies, AVAware has developed a new collection of catalog-related tools and features that are designed to extend the capabilities of the catalogs and make it possible to manage architectural hardware products like never before. This collection of software modules are woven throughout every aspect of the AVAproject system, from the catalogs themselves, to the catalog maintenance tool used to create the catalogs as well as AVAproject and AVAproject Fusion. Collectively, AVAware refers these modules as the "Catalog Kit" and represents a complete "game changer" in terms of how catalogs can be used and their products can be managed. The architectural hardware industry finally has a solution to the challenges presented by these products in terms of inventory control and management.
The “Catalog Kit” is scheduled to go into beta testing in the summer of 2014; look for updates and additional product details in upcoming edition of AVAwire or by following AVAware on any of the popular social media services.
|
