Archive for September, 2009

“What’s the difference?”

Monday, September 21st, 2009

I have worked for many years supporting major manufacturing clients with operations throughout the world. Often times it has been centered around product engineering support and product documentation. Everything from initial development, prototyping, testing, production, parts (production and after-market), operator and service documentation – soup to nuts. I have always been impressed by the great lengths companies go to ensuring that when the product is ready for market nothing has been left to chance. They know every part that is needed, whether custom built or purchased (supported by engineering drawings), the best price, lead time, how much inventory is needed, sourcing risks to consistent part numbering schema. Virtually every detail that needs to be done to get product successfully out the door and supported has been thought through numerous times.

As I have been working with indirect or non-production spare parts and commodities, I am equally surprised at how little thought of organization goes into the activities that supports the product build or even the facilities. Usually, I find that this whole issue is not dealt with in an organized fashion and is somewhat left to chance. All of the same thought that goes into product development should go into the manufacturing of the product. Why isn’t a Master Database of all indirect materials / commodities required for the Enterprise so the information can be commonly shared? With lead time, common pricing, warranty information, vendor or vendors, etc? First, no one individual owns the enterprise information across the different functional teams. Secondly, it is a decentralized task. Each individual manufacturing facility handles its own needs to get product out the door. In the meantime corporate purchasing is trying to support or at least get its arms around what the Enterprise needs.

By managing this spend consistently throughout the Enterprise, corporations can help ensure product gets out the door 24/7 and reduce their manufacturing cost substantially.

Who Represents the Data in your Master Data Management Software Systems Designs?

Thursday, September 17th, 2009

Those of us that are representatives of Master Data Management initiatives, data quality projects and the users working the processes developed by software makers have a difficult journey in front of us. It seems that for years software developers have designed cumbersome transactional data management systems that do not begin to understand real time data management and what effort it really takes to achieve an on-going Master Data Management program. I have two initial questions: Do these software companies toting one press release after another about Master Data Quality Management even understand the importance of on-going change management to a master data record? How does a business stay in front of the information flow if the software system does not dynamically adapt to the ebb and flow of data volumes and requirements? Software companies track updates and revisions to software code, data is of the same importance sometimes it is of greater importance; the number of data level updates can be monumental depending on the size of the company. Isn’t the end result of a multi-million dollar software system implementation supposed to drive efficiencies and streamline the activities to support their businesses? Cost saving and real time data management is the name of the game.

Here are a few data management tips:

1. Data needs a simple way to be imported into the system. Data comes from a number of sources so a dynamic mapping and import procedure to an internal processing area is useful for data analysis.
2. Yes, there needs to be an area to work on data before it is promoted to a Master Data Status. Software developers need to understand that data is never in a pristine state ready to be entered as a Master Data Record. Never!
3. Data processing requires a managed work flow through the system. Imagine the issue to have thousands of records for analyzing and many employees trying to manage who has what records outside the system. Just not functional work scenario.
4. Never copy data from one software module or grid to another, always reference. Cost per record to manage the data is increased every time a person needs to manually update an aspect of a record more than once.
5. Performance of the software is imperative. To really capitalize on software and technology reporting and analysis need to be done on thousands of records at a time. Time is money.
6. Provenance tracking is extremely imperative especially when “Cataloging @ Source” is the foundation to the quality of the record. Data should be identified with history: where the data originated, contact information, data and time, a revision level, file name, all associated records on the file, etc. MDM system developers, can you start to see the importance of this information?
7. Data needs to be cleansed and profiled; it is important that the software processing tools understand all aspects of the data. For instance search rules should not be so rigid that it takes an analyst manual actions to find a duplicate record because of an extra space or a slash. A worse case scenario is to take the data out of the system to work the data in excel, I am not going to even comment any more on that scenario except that it is totally unacceptable to remove data from a system to try to normalize it. Remember there is a lot of data brought into the business and the cost to manage the data is not core to the primary business, it is an indirect cost. The solution is not outsourcing to a “low cost, low skilled” worker in another country when much of the preprocessing can be done at the expense of CPU time.
8. Data changes, if you have a number of different modules in your software package what is the strategy to support aggregation of the changes to the different business units using the data? Does your software only update in one module and the other modules are in an out of sync situation? Again remember software should be designed to simplify the processes to support the business needs.
9. We live in a global economy language translation and localization of data is more important now than ever. What are the methods translate and maintain localized data?
10. Reporting and exporting of information is critical. It is a requirement to export a segment data set to send to a business customer or run a report of the activities of the work. A MDM system must be able audit data activities through the complete process of import through promotion to a master record.

I am a firm believer that software should not dictate a business process but should be designed to streamline and add efficiency to lower the cost the activity. If you are designing MDM systems, your team should include experts in data management, data quality and business process expertise with applicable experience. Businesses should not be paying for customizations to your software to be support basic 101 management of data.

View Jackie Roberts's profile on LinkedIn

Events DATAForge will be presenting at

Friday, September 11th, 2009

October 2009 is going to be a busy and exciting month for DATAForge. We are scheduled to present at two events and hope to see you all at both

DATAForge will be presenting at the FMMUG 2009 Best Practices to be held October 11th and 12th. This years event is to be hosted by Purdue University. The mission of the Facilities Management Maximo User Group (FMMUG) is to provide a forum for Maximo users in the facilities management industry to exchange information, methods and experiences. This exchange of information is designed to optimize the use of Maximo’s capabilities. For more information visit http://www.fmmug.org.

DATAForge will also be presenting on behalf of the Automotive Industry Content Standardization council at the 10th Annual ECCMA ISO 8000 Data Quality Conference on October 27th, 28th and 29th. This years event will be held at the historic Hotel Bethlehem in Bethlehem, Pennsylvania. Whether you are new to data quality or a seasoned professional, this conference will provide you with a unique opportunity to discuss the latest trends and check out the latest technology. If you have an interest in improving the accuracy of your vendor, material, service or asset masters, improving the descriptions in your ERP software or buy-side or sell-side catalogs or if you are looking for solutions to data integration challenges, the ECCMA conference is the place to be! Please visit the ECCMA website for more information.

The Electronic Commerce Code Management Association (ECCMA) has approved the formation of the Automotive Industry Content Standardization Council (AI-CSC)

Friday, September 11th, 2009

Bethlehem, PA (PRWEB) September 10, 2009 — The Electronic Commerce Code Management Association (ECCMA) has approved the formation of the Automotive Industry Content Standardization Council (AI-CSC) as the fifth council with direct editorial access to the ECCMA Open Technical dictionary (eOTD). Read More…

It’s Complicated

Wednesday, September 9th, 2009

At DATAForge we pride ourselves on designing simple, elegant, easy to use, web based software for a manufacturing demographic that has been flooded with overly complicated software, abound with options and restrictions, screens to control those options,restrictions and configurations. I’m tired of it. I don’t want you to get me wrong, there is certainly a time, place, and need for software that is configurable in every conceviable way. For example when a multi-state and international corporation is required by law to comply with one of the most complicated tax codes in the recorded history of Earth, then you get a pass for making an application complicated. In this case complication can and has saved many organizations millions or hundreds of millions of dollars, issues like The Sarbanes-Oxley Act of 2002 are not to be taken lightly.

The same logic of presenting every imaginable, option, configuration, button, screen, step, radio button, piece of information has been applied to many software packages. You would think in a large organization, simplicity would be king…not so…I am currently consulting with a large multi-national organization to help in the deploymentof a centralized system to house all product information for their MRO or Maintenance, Repair and Operations. Which, in practical terms, means that they are centralizing their databases of information required to order, maintain, and use any item that can potentially be purchased but does not go into their final product.

Not a small task by any measuring stick. Master Data Management, data cleansing, data normalization, intra-organization de-duplication are on the radar of most if not all large businesses. The most important part of the process is to choose application(s) that are the best fit for your organization, not the one that is made or owned by the largest company, and not the one who has the most clever marketing, not the one that appears in the latest report by the best marketed research firm (think about the ratings agencies who rated toxic subrime mortgage backed securities AA or AAA)

The software that was chosen xxxxxx (contractually obligated not to say the name) has one main screen for entering most of the data related to any given item, this screen contains no less than 50 possible fields in tabular form. There are also 3 additional screen each with less than 50 fields for data entry, these subsequent screens are used to associate ansillary information such as pictures to an item. The screens that DATAForge uses – one screen with 25 or less (depending on the type of data). The remainder of the information is gathered organically and seamlessly based on the way the application is used and who is using it.

When we design a solution the question on each team members mind is “How can I make this easier and faster to do for the end user?”

When evaluating an application force the vendor to show you how it will be used (not tell you), make them show you their solution is faster and more efficient. Lots of options, inputs, and fields are not always the users friend.

Life Cycle Data Management Strategy

Thursday, September 3rd, 2009

Life Cycle Management implies a single “cradle to grave” plan that integrates production support planning, acquisition and sustainment strategies. Think about the importance of data flow and the criticality of accurate data throughout the complete life cycle of a piece of equipment: design, build, install, spare part acquisition, inventory management, maintenance, spare parts sharing and finally, asset disposal. From a data perspective, remember the old computer motto: “Garbage In, Garbage Out”.

What is your Life Cycle Data Management Strategy?

1) Drawing Libraries – The items in the library need to be cleansed and profiled to a classification schema. The schema requires standard naming conventions and technical descriptions. The schema can be designed within your company, priority purchased from another vendor or you can opt for using an open classification dictionary for public use such as the ECCMA eOTD.

2) Common Component Listing – provides a listing of preferred components that support the inventory management strategies for your organization. All equipment designers and builder are required to use the common components identified. Note: common components are set up in the drawing libraries.

3) Spare Part Acquisition – Place the components on purchasing contacts at the beginning of design, this will facilitate the ease of spare parts planning and purchasing. An item on contract provides purchasing the data needed to run analytical algorithms in order to better negotiate pricing organization wide. If the item is set up accurately to a standardized classification dictionary with technical descriptions only one time the whole organization can realize the benefits of the Life Cycle Data Management Strategy.

4) Inventory – supports optimal inventory management by promoting the ability to plan stocking levels and strategies with nearby facilities. Think about the implementation of spare parts sharing or an internal purchase first program. The most important requirement is the standardization or normalization of the data; the part needs to be classified only one-way and should be shown in every system the same way.

5) Maintenance –The use of standardized components coupled with a data management strategy allows the organization to streamline the number of different components used to serve the same function on different equipment. Also reducing the number of parts in inventory and maintenance management tasks.

Life Cycle Data Management Plans starts with component standardization and cleansing the data in your equipment drawing libraries and all downward systems including maintenance. This strategy avoids duplicate inventory items and at the same time promotes an internal purchase philosophy that puts a priority on inventory sharing before issuing supplier purchase orders. Standardizing inventory with information elements such as predefined stocking levels, identification of critical inventory, functionally equivalent item identification and purchasing analytics as well as enhanced vendor management are all necessary steps for a manufacturing business to remain competitive in today’s world of lean low overhead manufacturing.

View Jackie Roberts's profile on LinkedIn