Posts Tagged ‘data’
Tuesday, June 15th, 2010
You would never believe the discussions around the “ho-hum” or “don’t sweat the small details” elements of a data cleansing project. Believe it or not, understanding your material type and material status is critical to be able to automate system updates. I have a firm belief that data updates to legacy systems should be completed as a night job or direct feed based a series of programmed templates. In one recent example we created an Oracle system update process for a new item referencing a material type template or another update process if the item is already set up for another location of use but is new to the requesting location, this is sometimes referred to as a location setup or purchasing organization update. You can start to imagine the amount pre-planning work and data mapping that is required for a data cleansing program.
The first fundamental rule is that the customer business doesn’t stop. For all you data purists out there that believe that one day a switch to turn on the cleansed database is in the near future, please include me, I would like to see it. Most master data management projects included years and years of legacy data; therefore there is an acceptance to draw a line in the database by last used date. When I design a data cleansing project, I will have a new item setup process referenced to legacy items, this way the client business continues and as the new items are analyzed and setup, we can reference and update the legacy item information. Independently, we will always have the legacy data cleansing parallel the new set up process.
As the data cleansing project is designed, let’s start to explore the data elements and classifications. Every client will have their material types and material status set up but generally during the data / systems assessment there should be a thorough review of industry standards vs. company processes. I find that our clients appreciate the opportunity to bench mark their processes and data structure elements such as material types and status. We will start with material type and material status.
Material Type
Material types can be as simple as goods and services or as complicated as service, critical spare, spare part, commodity, generic, blueprint, etc. The material type is a critical element to classify which template is used for setup in the downstream legacy systems with an inventory stocking strategy applied.
Obviously a service can be standardized by the class type to describe the service where a cost for the service can be standardized. The definition of the service is described by the properties, for instance a service class of CLEANING, OFFICE can be set up with descriptive elements such as 10,000 square feet, light cleansing (dusting / vacuuming), etc. From a purchasing perspective, the buyer can run the reports globally to determine how much is spent for office cleaning then evaluate the costs and utilize best practice sourcing strategies and other global supply chain processes to lower costs. The purpose of the standard naming conventions of classes and property are to provide enough standardize information to provide the ability to compare and cost services or products.
If a critical spare is being set up for sourcing and inventory, then the part has been evaluated by maintenance or engineering and determined that the spare is critical for production uptime. An inventory plan is developed for stocking the critical spare including an initial buy quantity, plan for stores (inventory) setup of item’s unit of measure (each, assembly, package, etc.), min / max, reorder quality, stocking location, etc.
Material Status
In addition to applying a “material type” to the item records, due to the longevity of materials used in the manufacturing operation, a material status should be utilized as a long term data maintenance process. In dealing with component manufacturers and suppliers, a component may be active from a plant use perspective; however the component manufacturer no longer manufactures the item. How is that possible? A piece of equipment can have a 10 year or a 50 year life span, to maintain a piece of equipment, a list of recommended spare parts is identified and set up for equipment maintenance. If the spare part component is obsolete by the manufacturer but the piece of equipment is still in use on the production line, the material status would be “obsolete active”. A different buy / stock strategy would be implemented, such as purchase all available stock from the manufacturer or another alternative is to source with unconventional methods such as through eBay or maybe contract the item to be built by a local shop.
Typical material statuses that I have experienced are active, inactive item referenced to an active item, obsolete active, obsolete inactive (typically the status to start the disposal process) and archive. The archive status is a classification used by the analysts to allow the viewing of the item information but is not visible to the client or the item record is not exported to the client systems.
I would appreciate any input or better yet a discussion of the different material types and material status used in Product Information Management (PIM) or Master Data Management (MDM). As an industry we inherited material types and material status used in a purchasing system or maintenance systems designed to meet business function but not from the data quality or master data management perspective. What are the proper data requirements for a material type or material status? The MDM or PIM software companies and data quality consultants need to provide input from the data management perspective to provide long term data management functionality.
Tags: Business Intelligence, data, data governance, data management, Data Profiling, data quality, DATAForge, dataquality, eOTD, linkedin, maintenance, manufacturing, masterdata, mdm, project management, spare parts, system implementation, Technology
Posted by Jackie Roberts | 1 Comment to View »
Wednesday, March 10th, 2010
Those of us that work around or manage the day to day operations of an MDM, data governance, or data cleansing projects understand the challenges and efforts needed to transform “raw” data though multiple stages of analytics and processes to achieve information quality to be used in our customer’s CRM, CMMS, PIM and ERP systems. The result of an un-cleansed product record can cause a production line to stay off line because an inventory item wasn’t ordered due to incomplete information or added inventory cost of ordering an incorrect item (we can be talking about a $10,000 motor) or multiple entries and setups in the material master due to data duplication.
Data vs. Information definition: to simplify the concept, data is managed by a combination of a team of analysts and software to achieve the goal of a cleansed record or useable information. Data is imported and profiled, classified, structured, verified, enriched, translated and reports generated; we create useable information from low quality data for use in decision making related to engineering, purchasing, maintenance, marketing, sales, etc. The data that is exported into client systems is information that will meet a predetermined set of data governance rules and information quality requirements.
Data Quality Experts, let have a discussion on the definitions of data quality, does an address or a product detail meet the requirement if only classified? Or should verification at source (contact for address or manufacturer / supplier for product) be required at initial setup of the data in the system or maintenance scheduled as part of the data governance program? Is the data incomplete? Does the MDM process include a question / answer scenario to complete the data?
MDM software designers and developers can we also have a discussion on the software’s ease of use to manage the stages of data cleansing to support a MDM philosophy and using advanced techniques to automate the management, add intelligence in processing data imports, workflows and data cleansing stages of classifying, profiling, matching, translation, data audit analytics, exception reports and status reporting of a data record?
I believe these are great discussion points and will serve as great blog topics.
Tags: Business Intelligence, data, Data Cleansing, Data Profiling, data quality, DATAForge, dataquality, linkedin, maintenance, masterdata, mdm
Posted by Jackie Roberts | 5 Comments to View »
Thursday, February 4th, 2010
Dear Andrew White,
Thank you for your comments in “Something beyond MDM is coming your way – would MDM 2.0 fly?” and starting the discussion to expand the definition of MDM to include data integrity, data quality, entity resolution, matching, data integration, governance, metrics and analysis. The topics discussed should also include work flow (management of data and analysts), translation management, data structuring, data profiling, duplication removal, data change management, verification contact management, etc.
The MDM and PIM software industry needs to take a step back to understand actual day to day business requirements of data management to achieve Master Data Quality. Lesson one is that data is created and supplied by many sources in many different formats at various quality levels. Data is created by engineering, submitted by integrators, manufacturers and suppliers. To add to the complexity of the information flow, data is introduced into businesses systems in different departments (engineering or purchasing or maybe plant from maintenance) with different data requirements to meet the needs of that job function. Now the next dynamic is mashing new data to existing legacy data in a number of systems to ensure no duplicates are created, managing obsolete / recommended use and functional equivalents. The old philosophies of a PIM or MDM software to “hold, provide search functionality and maybe a shopping cart” isn’t going to meet the true requirements of the new definitions of Master Data Management.
To meet the new definitions the MDM or PIM software needs to provide horse power to electronically and intelligently processing data to identify exceptions for manual intervention by an analyst. Data should be processed one time to ensure that the data record will be enriched to meet the requirements of the enterprise and then the record is moved to a maintenance program (managed also by the MDM or PIM software). The processing of data needs to be efficient and cost effective, from my perspective the cost of data management should be covered by the cost saving achieved by MDM management.
I look forward to the discussions as the definition of MDM is expanded to include data quality, data governance, data provenience as the software industry provides the intelligence, functionality and business processes to cleanse, enrich and management data for my client to ensure their ability to make confident business decisions based on data integrity and accuracy.
Here is to the future of PIM and MDM!
Jackie Roberts
Tags: Andrew White, BPO, Business Intelligence, data, Data Cleansing, data management, data quality, DATAForge, development, Gartner, linkedin, maintenance, manufacturing, masterdata, Maximo, mdm, MRO, SaaS, Software as a Service, system implementation, Technology
Posted by Jackie Roberts | 2 Comments to View »
Monday, January 25th, 2010
Our work encompasses a large number of spare part records, each part records flows through our data management and verification process. A large number of spare parts could be as many 250,000 to 300,000 records references to as many as 10,000 pieces of equipment for just one program. As you can imagine tracking each part record is a challenge and the complexity of maintaining data change history for your business should be evaluated when considering a PIM software deployment.
The requirements for our clients business requires the complete documentation of spare part record change history including: Spare parts list submitted by, equipment used on, location of equipment, verification and data enrichment including who verified, change in information, when, etc. Why is this information important?
1. Spare Parts List – The supplier submitted spare parts list should be made a mandatory requirement for equipment design and build. In order to support a maintenance organization all suppliers should submit a full bill of material with recommended spare parts identified for the equipment they plan to deliver. The supplier requirement should include the original manufacturer for each spare part. Additional information tracked should include who submitted, file name, equipment name, equipment warranty, terms of warranty, when submitted and all contact information.
2. Use on Equipment – each spare parts list should include equipment part or model number, standardized name and a category of equipment. The standardized naming conventions are extremely beneficial for multi-facility maintenance use and will support common tasking procedures.
3. Location of Equipment – this information is essential for the export to a CMS maintenance system enabling spare parts to be set up for maintenance, work orders created and tracked and asset management.
4. Verification – is essential for accuracy of data quality. The verification process of a spare part is sometimes a true investigation. We receive data with suppliers listed as the manufacturer, partial part numbers, conflicting descriptions, incomplete descriptions, etc. Each data element change should be documented with when changed, who revised, what was changed and why.
5. Data Enrichment – What does the full enterprise (purchasing, engineering or maintenance) need to support the business activity? A spare part record should be touched 1 time and all information required should be included at the time the record is set up. Data Enrichment will include a reference to a class (category), required attributes to describe the part supporting the technical long description, estimated price, ECCN (Export Compliance Classification Number), UNSPSC® (United Nations Standard Products and Services Code®), lead time, warranty, terms of warranty, tasking information, etc.
In order to implement an accountable data governance program and useable data structure, a well planned data mapping should be documented for legacy systems of the enterprise. A complete data governance program will enable new efficiencies for data processing and the management of improved business processes such as parts sharing, identifying critical spares, strategic spare parts purchasing, and warehousing.
Tags: BPO, Business Intelligence, data, data management, data quality, DATAForge, linkedin, maintenance, manufacturing, Maximo, mdm, MRO, spare parts, Technology
Posted by Jackie Roberts | 3 Comments to View »
Friday, January 8th, 2010
With the ever increasing emphasis on finding ways to reduce cost, one of the clear targets is IT and more specifically data management systems. On the surface it can seem like there is real fat to trim, and many times this is true. But it is easy to become lost in the details and eliminate or negate some of the potential savings. Some of these ideas may seem obvious but are often forgotten. The evidence is clear with missed timing and over budget issues seen.
If we’re talking about a large company then inevitably with this new system comes the monolith project with whole organizations of people and processes, projects and documentation. The compulsion is to be sure that everyone, everywhere who has any relationship to it has their input and their needs accounted for. Along the way, the cost of implementation and other peripheral indirect costs have likely negated a great deal of at least any short term savings. Not to mention the potential increase in continuous maintenance costs and loss in performance. These are a few things I’ve learned from experience and I welcome yours.
Always have a specific objective when planning for development or evaluating software to purchase that overrides all others. Start with something like a mission statement, “We need this new system for….”
Determine the Real Needs. Try to separate the “must haves” from the “nice to haves”. Bells and whistles are great but there needs to be a true benefit. Seek a balance between development time, software performance, hardware performance and user experience. I always try to put special emphasis on the user group which stands to benefit the most. Having many users who can do their job faster and more efficiently can add up to real savings versus the few users who have a special need which bogs down the project and performance.
Change is inevitable. If some requests for additional features come along, evaluate them against the mission objective. There is nothing wrong with listening and investigating ideas for project add-ons as long as the benefits outweigh the costs in time and money, but there needs to be a limit or you’ll never complete the project. Good ideas can always be implemented later if it makes sense then you’ll have the benefit of the research already done, but be quick with the research. Evaluate the impact for doing it now or waiting. Here are some good questions to start with: 1) How much more money? 2) Would this be faster/cheaper for programming to do it now versus waiting and doing a more complicated enhancement? 3) Is the impact to the users great enough to warrant it?
Know the roles. Good ideas can come from anyone. Every project must have a project champion who makes the final decisions (and live with them) and also eliminate roadblocks. You need a user advocate who has done the job and knows what it takes. Have programmers who possess both talent and vision, not just code crunchers, and listen to them.
Have good documentation, and “Good” is subject to interpretation. This is another area where the KISS principle is very often not utilized. If you have to hire ten people to sit in meetings just to maintain your documentation you’ve probably overcomplicated it and certainly increased your project cost. I try to start with these principles:
- Document the people on the project and their responsibilities. Let there be no question as to who does what.
- Everyone who has a job to do needs to understand what they need to do and have the documentation to reference.
- Keep the language simple. Focus on getting the point across. If it takes a rocket scientist to understand it you’ve failed.
- Of course, document the issues, decisions made, by whom etc. but be sensible. Document enough to cover for the “he said/she said” but content is most important. No bonus points for flash.
- Know who is supposed to have what done and when. Another obvious one here but I see too often where target dates are determined top down with little or no thought to cost or the tasks. Don’t let the tail wag the dog. Pushing hard to get the job done is fine but be realistic. Listen to the people who know before making bold predictions.
Tags: Agile, automotive, BPO, Business Intelligence, data, Data Cleansing, data management, data quality, DATAForge, dataquality, development, eOTD, ERP, linkedin, maintenance, manufacturing, masterdata, Maximo, mdm, MRO, project management, SaaS, Software as a Service, spare parts, system implementation, Technology
Posted by Carl Hamlett | Post a Comment! »
Wednesday, December 2nd, 2009
As the Master Data Management industry matures, the industry focus is not only on the development of software to collect product records but software to implement the data quality process solutions supporting data governance and provenance including record history, structure, completeness and accuracy to ensure our customers are able to make confident, informed and accurate business decisions based on data accuracy. The first step of implementing a data governance program is implementing a naming classification system.
I have had experience working with single business home-grown classification structures and third party developed structures for purchase, currently I have chosen an open and public classification structure provided by ECCMA (www.eccma.org). This is beneficial to the customers that I support ensuring that they will always have access to the classification structure sometime referred to as the schema used to classify their data.
Implementing a classification requires setting up Identification Guide (IG) to establish the template definition to technically describe the product or service with enough information to support engineering, maintenance or purchasing while recognizing the limitation of software short and long description required character lengths. The IG template supports and simplifies the required information request to the manufacturer and suppliers to verify all information by our analysts to standardize the description.
To create an IG, we search the ECCMA class list; fortunately many of the classes are established. As the IG is set up we will use the ECCMA established class name convention; this will ensure that every item will be setup with the same name and format, every ball bearing item submitted will be classified as a BEARING, BALL.
The next step is to set up the properties required to describe the BEARING, BALL and for each property designated the data type requirements such as numeric, text string or designated unit of measure. The property value requirements for a BEARING, BALL might include TYPE, BORE DIAMETER, OUTSIDE DIAMETER, WIDTH, DYNAMIC LOAD CAPACITY, STATIC LOAD CAPACITY, MATERIAL and so forth. Our analysts will verify the data to the original manufacturer sometimes using xml to exchange the product information referred to as “Cataloging at Source”, the information requests are standardized and remove much of the quality issues commonly found in a non-standardized data verification or description process.
The property value description build is controlled by the sequence number of each property Item data that will make it’s way into a length restricted description field we place the most important information in the begin of the auto generated description.
Setting up the Identification Guides requires upfront strategic planning and detailed work, as you can imagine that a classification schema can be up to 10,000 classes depending on the industry but it provides a multitude of benefits including standardized requirements, a road map for our analysts to facilitate the process, improved data management reporting / metrics and enhances language translation for the global organization.
Tags: BPO, Business Intelligence, data, Data Cleansing, dataquality, eOTD, linkedin, masterdata, mdm, Software as a Service, spare parts
Posted by Jackie Roberts | Post a Comment! »
Friday, October 23rd, 2009
With all the discussion focusing on Master Data Management and Data Quality, I always come back to these questions: How is the data structured and how is the accuracy and content completeness measured? In our business of managing the coding and verification of items and spare part information needed to keep manufacturing plants running, a structured schema of naming conventions (class), descriptive attribute standardization (properties) and verification at the sources of manufacture (coding @ source) is “key” to quality and completeness measurement. We are managing the ECCMA eOTD for the Automotive Industry Content Standards Council (AICSC) focusing on MRO naming definitions which is the foundation to a spare part description, just as a table of contents is the foundation of a text book.
The first step is to develop the Identification Guide (IG) in order to baseline the properties needed to best describe the class. For example, let’s take the class of SCREW, SHOULDER and the properties TYPE, MATERIAL, FINISH, THREAD SIZE, DRIVE SIZE, SHOULDER DIAMETER, SHOULDER LENGTH, THREAD LENGTH, HEAD DIAMETER, HEAD HEIGHT, SHOULDER LENGTH TOLERANCE, MINIMUM TENSILE STRENGTH, CLASS, HARDNESS RATING and PACKAGE QUANTITY. The IG also provides the information needed for our analysts to acquire properties and our applications to sequence the properties within the short and long descriptions that are built:
SCREW,SHOULDER – | TYPE: HEX HEAD | MATERIAL: 18-8 STAINLESS STEEL | FINISH: PLAIN | HEAD STYLE: HEX | THREAD SIZE: 3/8-16 INCHES | DRIVE SIZE: 3/4 INCHES | SHOULDER DIAMETER: 1/2 INCHES | SHOULDER LENGTH: 2-1/2 INCHES | THREAD LENGTH: 3/4 INCHES | HEAD DIAMETER: 3/4 INCHES | HEAD HEIGHT: 1/4 INCHES | SHOULDER LENGTH TOLERANCE: ±0.005 INCHES | MINIMUM TENSILE STRENGTH: 80.000 POUND-FORCE PER SQUARE INCH | CLASS: 2A | HARDNESS RATING: B85 TO B95 ROCKWELL A | PACKAGE QUANTITY: 2
Each time an item is submitted for coding or processing the item is imported into a master database. Through intervention by our data analysts, the item navigates its way through a number of checkpoints including an auto-suggest to propose a class. The class and properties via the IG are the requirements our coding analysts use to verify the accuracy of the information submitted, to verify the completeness and to acquire the additional information needed to enhance and build an item or spare part description for our clients to base real business decisions.
The implementation of the eOTD is a two process scenario when working with our clients. First, the legacy data is mapped to the class, the item data is profiled, cleansed and enhanced to meet the requirements of eOTD IG, ensuring the client’s data quality goals are met. The updated item information needs to be applied to existing client item data. It is critical that all changes to data be tracked and logged. A properly planned and executed update to legacy ERP and CMMS systems should be initiated to incorporate the enhanced and corrected item information into the user facing systems. This is an extremely critical step as the downstream information flow will affect systems and uses such as inventory re-distribution, purchasing and contract management, engineering bills of materials and maintenance schedules. A thorough and complete mapping of data through the enterprise should be used to understand data flow across all business units. The mapping should include data entry points and data use points through all departments which set up all of the cost saving pay points as the data processing is streamlined.
The second process is an on-going data maintenance plan for new items that are introduced into the organization. This process should start at the introduction of item information into the system. All items and spare part information should be verified with the manufacturer and classified to the eOTD before setup or use in any system. The length of time the coding process requires is a critical element as the item or spare part information should be as complete as possible while at the same time be ready and waiting for the buyer to put the item on a contact or a maintenance employee to setup the tasking information in the CMMS for a piece of equipment. The only requirement for the employees who use the information after its initial entry into the system is to perform the actual requirement of their job and not to decipher a cryptic unstructured description.
If the items are pre-processed using the eOTD and the associated ISO standards, every item and spare part will be structured and standardized. The engineering, purchasing and maintenance departments will focus on the core of their day to day specialized responsibilities instead of searching for parts or dealing with trying to purchase items that a supplier does not recognize or have to acquire the missing information.
We all agree on some of the basic benefits both in process and cost such as reducing inventory with the identification of duplicate items, facilitation of inventory sharing and internal purchasing programs, reduced employee time searching for parts, common spare part usage strategies, reduced downtime in manufacturing equipment due to lack of information availability and ability to manage using a just in-time inventory model. The eOTD and its Identification guides are the building blocks and the roadmap to achieving structured and accurate data that can be reliably used to base real world decisions.
For more information on the eOTD please visit www.eccma.org.
Tags: automotive, BPO, Business Intelligence, data, Data Cleansing, data quality, DATAForge, dataquality, eOTD, linkedin, maintenance, masterdata, Maximo, mdm, MRO, spare parts
Posted by Jackie Roberts | 1 Comment to View »
Tuesday, October 6th, 2009
The difference between a Decision and a decision is simple. A Decision spelled with an uppercase “D” is one based on data, information and real-life experience. A decision spelled with a lowercase “d” is one made without data, information or a real-life experience. All too often I have seen decisions based on an individual’s feelings or opinions of a given situation. It makes me shake my head. In some cases, a business will use an algorithm or spreadsheet with embedded formulas to “choose” the best decision based on a set of desired requirements and associated weights applied to each requirement. For certain decisions, this might be the most appropriate way to assess the situation. For me, working to develop web-based software applications, it just doesn’t work.
The most common method of decision making during a development cycle I have come in contact with is the “committee” driven requirements analysis. During this process a group of usually high level managers (far from end users) sit down and work their way through a spreadsheet of requirements to decide which ones should be included in the next six-month iteration of development. In my experience, the only information included in the requirement column is the perceived expected behavior or outcome of the given feature or change. The end of this type of development cycle is usually followed by hundreds of hours of testing and arguing about how each feature should work, how it actually works and how we ‘thought” it would work. As well as two strokes, three heart attacks and a combined three square inches of newly exposed scalp for the male members of the team…
Every day I make decisions. Some turn out to be the right ones. Some turn out to be horribly wrong. Since I accepted the role of product manager rather than simply a project team member, I have put a great deal of thought around decision making. I ask myself questions like: “What information do I need to make a decision the right one?,” “At what point do I have enough information to make the decision?,” “Does the outcome of each decision I make effect the remainder of the product launch in a positive way?” I still can not answer all the questions I have about decision making. However, I have used the following principles to aid in making the right decision most of the time:
1.) Make lots and lots of small Decisions. When you send your developers off on a mission to complete a large section of code or forge an entire revision to an app in one shot, there are inevitably a lot of decisions that have to be made along the way. If your development team has to make these decisions on the fly, against an imaginary timeline, there is a large chance the decisions will be made without all pertinent information. It’s more likely each small Decision will be the right one if you use all the information available from the complete team at each point a decision is required.
2.) Keep the communication channels open between developer and subject matter experts. I recommend daily touch points of less than 15 minutes. Meetings are expensive, time consuming and often attendees are never prepared. I prefer discussions to take place at the programmer’s workstation while he or she is working on changes. This allows demonstrations of current and expected behavior to be shown immediately. Real information and real code turns into a visual aid. It is important all team members understand the purpose is not to meet the schedule. The real purpose is to launch an application people love to use. I might go as far as saying it should be expected that as you move from design to development, you’ll need to make lots of little changes along the way. I question any development cycle where there is little difference between the original designs and the product at launch.
3.) Test, Test, Test. After each Decision there should be some time spent to test it. Testing does not have to be a project in itself. Testing should be performed by both developer and the team member who is in the best position to interpret what will and will not benefit the end user. Testing at each available opportunity is essential to minimizing the amount of change required after a bad decision is made. For example, if a change is made and not tested, each change implemented from that point forward could require revisiting if it’s found the original change was in error.
These principles also contribute to a pleasure filled work environment by allowing each team member to work on what they love. Development does not have to sit in endless conceptual meetings, nor does the product management team need to wait months or weeks to debut new features. The three principles I illustrated above can and should be applied to any development scenario. Using these principles to govern product testing and design reduces our development cost and gets our product to users faster. And in the end, that’s what it’s all about.
Tags: Agile, data, DATAForge, dataquality, development, linkedin, masterdata, national security, scrum, Technology
Posted by Chris Roberts | Post a Comment! »
Thursday, October 1st, 2009
I am all about the data, location management (to location and equipment), data quality, and methods to improve auto-processing, enhancing data, providing data reports and results that support our customer’s data requirements in their day to day activities.
Here is the million dollar question, this is one scenario: Over a million records in a year, legacy and new records submitted for processing from 2,500 different users and two different business processes (single submit and BOM extract). What technology would be required to intelligently automate the processing of these records to a Master Data Quality Standard?
Remember this is an on-going maintenance process, not a one time migration of non-cleansed data to a new ERP or maintenance system, nor am I referring to parsing the records into different fields of the new ERP system but ensuring that the records are verified, structured, properly attributed with full descriptions and additional information to support the business needs.
First, let’s look at the Wikipedia definition of Product Information Management (PIM) “PIM systems generally need to support multiple geographic locations, multi-lingual data, and maintenance and modification of product information within a centralized catalog to provide consistently accurate information to multiple channels in a cost-effective manner.”
Future PIM software purchasers, what evaluation methods are you using to ensure that your PIM software purchase will support the continuous update and flow of data for your entire enterprise system? Here are some items to take into consideration during your evaluation, these are all items that I ask about and would recommend that you request the answers in writing:
1. How is the change history of the data stored in the system and how easily can it be retrieved?
2. Has the performance of all modules of the software been tested and what is the base line?
3. Request references (at least three) for each module of the software.
4. What is the software product work flow and how is the data processing assigned to employees?
5. Ask to review the documentation and take the time to review; this should be a window into the complexity of the system.
6. Request the design process model and how the software company incorporates customer feedback?
7. What is the bug fix process? What is the quality system to implement a bug fix?
8. What is the software company’s philosophy on customizations at your cost?
9. How is language handled? Translations referenced to a master record?
10. If the software solution is multi module system, how are the master records referenced through
the entire solution?
11. What are the long term design strategies or road maps for each module of the software solution? Ask for the earlier road maps and the software release note to evaluate the how well the software company plans and implement updates to the systems.
And I can go on and on, the licensing; customizing and implementing software in your environment can be extremely costly and time consuming, does Caveat emptor “Let the buyer beware” work in the business world or is there a “Lemon Law” when purchasing software?
Tags: BPO, Business Intelligence, data, Data Cleansing, data quality, DATAForge, eOTD, linkedin, maintenance, manufacturing, masterdata, Maximo, mdm, Software as a Service, spare parts, Technology
Posted by Jackie Roberts | Post a Comment! »
Thursday, October 1st, 2009
My company’s fiscal year is based on the calendar year as many others are. So, customarily we start the budget planning process in October. It is a detailed process that all of my managers and business units participate in. We usually do a few iterations before it is finalized in mid December. Sound familiar? So here’s the question, after 2009, how do you plan for 2010? Everything we knew and could usually predict with some certainty in recent years went out the window in 2009. Where do you start to plan for the next year? Is it too early to plan for growth, if not, at what pace? What certainty can we count on when developing our plans? The simple fact is, for most of us, we don’t know enough at this stage in the recovery to forecast with certainty where our businesses will be, at least, through mid next year.
So what can be done to insure profitability, or least stability, until growth returns? Control and further reduce costs. Already been there, done that? You have cut staff, benefits, wages, renegotiated prices and terms with suppliers, cut services, slowed production, cut inventories, everything you can think of. Are you sure? How well do you manage your Enterprise wide Master Data Indirect Materials / Commodities spend? What? Everything you buy that supports your facilities and the build of your products. Most large manufactures manage direct material precisely but don’t have an organized approach to their full advantage throughout the Enterprise to strategically manage indirect materials. A solution, fully implemented, provides a number of benefits:
1. “Cleansed” data, eliminating duplication of the same item coded to several different part numbers.
2. Consistent pricing for each and every part / component verified to the OEM level with lead time and warranty information. Minimizing your need to buy spare parts / commodities from distributors or your build sources.
3. Enterprise-wide material management to the department level in every Manufacturing Operation.
4. A reuse or repurposing of excess inventory in Manufacturing Engineering.
5. Able to search inventory with standardized part naming conventions and in multiple languages.
Bottom-line, an aggressive Enterprise wide well executed strategy can and will save your company significant dollars in the first 12 months of implementation. That’s 2010 folks….
Tags: BPO, Business Intelligence, data, Data Cleansing, DATAForge, dataquality, linkedin, maintenance, manufacturing, masterdata, Maximo, mdm, MRO, Software as a Service, spare parts, Technology
Posted by Art Healan | Post a Comment! »