Accessing All of Your Product Data Regardless of Where and How it is Stored

Share

A quick peek into some research on … the importance of accessing all product-related information, whether it is stored in a formal system such as Product Data Management (PDM) or not. The report, Issue in Focus: Product Data Accessibility: Getting Value from All of your Product Data, explains the importance for manufacturers to readily retrieve product data and points out that there are emerging technologies that can help.

The Research Findings

I have reported on the importance of product data many times, including Tech-Clarity’s The Business Value of Product Data Management: Achieving Rapid and Extendible Benefits and Managing Engineering Data – The Role of Product Data Management in Improving Engineering Efficiency. In the PDM report, I talked about three fundamentals of PDM:

  • Control and secure product-related data
  • Improve the ability to quickly find and reuse information
  • Share product knowledge with other departments

But the report discusses the reality that, as the report says, “Many companies don’t have centralized product data, and even those that do typically have a lot of product-related data spread out across the business that isn’t centralized.” Manufactures have to live with the following realities:

  • Not all companies have been able to control their product data in this way (due to software or implementations costs or other factors like acquisitions that leave companies with multiple processes and solutions)
  • Many companies are handling the control of their data manually
  • Most companies have product data that will probably never be under control of a formal system, including documents and spreadsheets that reference parts and products
  • Most manufacturers have important information in their ERP, SCM, CRM, and other systems that can be valuable

The report also makes an important conclusion that “accessing product data and centralizing it are not absolutely linked, and there are emerging technologies that help engineers access data without having to consolidate it in a central location.” These new technologies can help engineers stop wasting time looking for data. In addition, they can intelligently aggregate (‘mash up”) if you will, data from different sources to see the big picture and make better decisions.

Implications for Manufacturers

I am not coming out against PDM. PDM offers valuable functions that allow companies to control their product data. Capabilities like revision control, check-in/out, and approval cycles are important. For companies that need to manage complex relationships between files, including 3D CAD assemblies, there are important features in PDM. But if you find yourself facing one or more of the realities above (I would bet that includes 90% or more manufacturers) then you have to live in your current reality. And realize that your reality may change in the blink of an acquisition.

Manufacturers should check out the new class of technologies that is evolving aimed at allowing companies to quickly assemble their information in much the same way that a search engine like Google. These technologies are absolutely worth a look. Should we call the “PDA” for Product Data Accessibility? Or product data search? But both seem to fall short when you consider what they can do to not only find but assemble and act on the data. Time will tell. Will they replace the need for PDM? Will they augment an existing PDM implementation (or multiple implementations, as some companies have)? It really depends on your business, but I envision it serving all of these needs. But the simple truth is that companies need to access all of their product data and put it into context in order to make good decisions. A product data accessibility approach allows them to access their information quickly, regardless of the reality they live in.

So that was a quick peek into some recent research on product data accessibility, I hope you found it interesting. Does the research reflect your experiences? Do you see it differently? Let us know what it looks like from your perspective. Please feel free to review more free research and white papers about product data and other enterprise software for manufacturers from Tech-Clarity.

Comments

  1. Agammelgard says:

    There are many 3 letter acronyms that exist to help manage product data as it flows from engineering, through manufacturing, through the supply chain, and out to customers, but I think what it boils down to is a need for collaboration, and centralization. Manufacturers need a simple, easy way to manage their BOM (items, AML, files) to manage their BOM as it changes, and to keep suppliers up-to-date. 

    I know Arena Solutions offers products that do just that – - and do it in the cloud. But I wouldn’t call Arena a PLM or PDM company. I think people get hung up in looking for something that fits the big “business systems implementation” model, and that just doesn’t seem like a modern way to do business anymore. 

    • Eric says:

      I have been thinking along similar terms, where it would be nice to have a system that at its core tracked items, BOMs, AML information, documents, etc. Also, revisions and changes. But the core itself is solid and lightweight, using a well designed web interface. To this you could add modular functionality, but the core itself is this solid data store with web APIs (SOAP, REST, whatever) for integrations. Arena has a nice UI from what I have seen, but myself I still see this as possible for internal hosting. Anyway, I see a need for a simple system to hit a certain segment of the market that has a need for this.

      • Eric,
        I think part of the challenge for software vendors is developing something simple and clean and then having customers ask for numerous enhancements to handle all of the exceptions. It seems like most companies have a hard time developing something simple that meets 80% of the needs without adding complexity to chip away at the 20% (that is different for different companies). The result is complex and (sometimes) brittle systems that hard to use and hard to develop.

        So is there space for the simple solution that works well in most situations for most people, versus trying to meet a larger percentage of needs for certain communities? And if so, which is Autodesk building?

        If Autodesk focuses on the infrastructure and allows industry experts and individual companies to template/configure the processes do they avoid this scenario and allow their solution to stay simple?

        Good food for thought, it will be interesting to see what 2012 brings!

      • OK, replying to my own reply. I may have mixed apples and oranges by bringing up Autodesk. I was thinking of the Nexus solution they are bringing to market from this post -tech-clarity.com/clarityonplm/2011/autodesk-plm/ – but I noticed this comment was related to accessing product data. Sorry if I confused anyone!

  2. Agammelgard says:

    There are many 3 letter acronyms that exist to help manage product data as it flows from engineering, through manufacturing, through the supply chain, and out to customers, but I think what it boils down to is a need for collaboration, and centralization. Manufacturers need a simple, easy way to manage their BOM (items, AML, files) to manage their BOM as it changes, and to keep suppliers up-to-date. 

    I know Arena Solutions offers products that do just that – - and do it in the cloud. But I wouldn’t call Arena a PLM or PDM company. I think people get hung up in looking for something that fits the big “business systems implementation” model, and that just doesn’t seem like a modern way to do business anymore. 

    • Jim Brown says:

      Thanks for your comment. I think collaboration is a huge need, and as supply chains (and companies themselves) get more virtual and distributed it gets both more important and more difficult at the same time. I do think there is value in controlling data, including defining all of the relationships between information. Having control is an investment, and helps people ensure that the information they access is the right version, etc. A lot of companies just don’t have that, and sometimes they feel PDM is too expensive or too much of a burden. So why not have the information assembled and presented regardless of where it is? And the relationships determined automatically? I think this is a very modern approach. I don’t think that the old approaches will die out, but having the ability to search out product data and bring it back in a usable way opens up great opportunities.

    • Eric says:

      I have been thinking along similar terms, where it would be nice to have a system that at its core tracked items, BOMs, AML information, documents, etc. Also, revisions and changes. But the core itself is solid and lightweight, using a well designed web interface. To this you could add modular functionality, but the core itself is this solid data store with web APIs (SOAP, REST, whatever) for integrations. Arena has a nice UI from what I have seen, but myself I still see this as possible for internal hosting. Anyway, I see a need for a simple system to hit a certain segment of the market that has a need for this.

      • Jim Brown says:

        Eric,
        I agree that it would be nice to have a simple system to help manage information. From what I have found, the simple systems end up growing complex due to the complexity of developing products. I wrote about the Five Dimensions of Product Complexity (http://tech-clarity.com/clarityonplm/2010/product-complexity-with-plm/), and how PLM helps. Is there a simpler version of PLM that still addresses these complexities? Autodesk just announced Nexus, maybe that will be a solution for some?

        Thanks,
        Jim

      • Eric,
        I think part of the challenge for software vendors is developing something simple and clean and then having customers ask for numerous enhancements to handle all of the exceptions. It seems like most companies have a hard time developing something simple that meets 80% of the needs without adding complexity to chip away at the 20% (that is different for different companies). The result is complex and (sometimes) brittle systems that hard to use and hard to develop.

        So is there space for the simple solution that works well in most situations for most people, versus trying to meet a larger percentage of needs for certain communities? And if so, which is Autodesk building?

        If Autodesk focuses on the infrastructure and allows industry experts and individual companies to template/configure the processes do they avoid this scenario and allow their solution to stay simple?

        Good food for thought, it will be interesting to see what 2012 brings!

      • OK, replying to my own reply. I may have mixed apples and oranges by bringing up Autodesk. I was thinking of the Nexus solution they are bringing to market from this post -tech-clarity.com/clarityonplm/2011/autodesk-plm/ – but I noticed this comment was related to accessing product data. Sorry if I confused anyone!

  3. This comment came from Rory Granros on a LinkedIn Group. Given the in-depth question, I am copying it here in order to respond more thoroughly:

    Like SCM’s move from
    “push to pull” or “outside in” strategy, I believe that PLM/PDM needs evolve to
    include customer or market focusing support. In the early or later stages of a
    lifecycle, informed decisions required unstructured and data from multiple
    sources. Our customers are starting to ask about “granular product content
    networks”. They envision both internal and external content networks. Each
    network will control access to one or more sources, compilation/transform into
    specialized formats, and dynamic publishing/amendment of information, change
    management and distribution. As external information demands increase, internal
    users will mandate one click access to their information and the need to
    publish into more external destinations will increase.

     

    I apologize the
    length of this post but this posting was 20 years in the making. One is
    assumption is information is available in the all the required formats. Based
    on several decades of process industry PDM/PLM experience, we seeing evolution
    in PLM usage and more customers are mandating additional usages of product
    information.

    Even though their system can have 1,000,000’s of
    formulas with associated packaging, labeling, compliance and specification
    information, sales, marketing and supply chain teams cannot easily access the
    required information. Most often, these teams have manual processes to plug the
    gap.

    As the rate of change of formulation change is ramping
    and these teams get slammed and the time to sales enable is increased and risks
    to brand equity is increased. Often, the next formula version is available
    before the previous formula version’s sales enablement is completed.

    Why? One issue is the increasing rate of customer
    requirements. Big retailer/b2b customer are becoming more demanding. Few PLM
    solutions can deal with weekly or even monthly reconfiguration and associated
    change management issues. The second issue will be required increase in
    required data maintenance. If you previous PLM process certified the formula
    and FG spec, adding 10 or more sales teams to the process can significantly
    extend the time to market. While adding these groups to the process is the
    right thing to do, more companies focus on the certification of product and not
    sales enablement. It is easier for PLM to just bypass these two issues and only
    maintain bulk formulas and only Specifications for FG. The result is an
    information gap. As we work with customers, we are creating one or more of
    these product content networks. The network starts with any available PLM or
    enterprise data, consolidates the information into product, channel or customer
    specific information. The network specific processes allow the appropriate
    users to hide and amend information, approve the information, and publish the
    information to multiple destinations. To ensure compliance, we configure the
    PLM to approve the output, write back to PLM or our Product Content application
    and ensure the one version of truth without impacting the traditional PLM users.
    It is a win win!

    While some say “must be a PLM solution issue”, you
    have to understand that one bulk product , “like latex white paint” can be sold
    into 5 or more package sizes, have plant specific or seasonal formulation
    variants, sold as branded and private label in stores and used by other
    manufacturers. At the moment of truth for each buyer and product category, the
    information content and method of delivery is different. With every change to
    formula, you impact 100’s of customer document or data feeds. If you add time
    to your PLM processes to add every unique data usage, you will add significant
    time and this is not politically acceptable. You standard processes can used to
    ensure compliance and update enterprise systems. Product Content Networks put
    the ownership for unique data on the appropriate owners. They have can staff
    the tasks and fund change management requirements.

    One last challenge is that not all SKUs are sold at
    the same rate. With publication rules, we can create data for commonly sold
    information and allow on demand publishing for infrequently used products. To
    make this work, your sales and marketing or customer will continually change
    their requirements. Few PLM or customer can deal associated PLM change
    management.

    Like PPM or new simulaiton applications, we see a new
    category or addon solutions for industyr specific Product Content Network
    applications. For both internal usage and emerging social marketing needs, the
    Product Content Networks will allow you ensure consistency of your product
    information across your internal divisions and external channels. You can drive
    more revenue and protect your brands across multiple channels.

    rory

  4. This comment came from Rory Granros on a LinkedIn Group. Given the in-depth question, I am copying it here in order to respond more thoroughly:

    Like SCM’s move from
    “push to pull” or “outside in” strategy, I believe that PLM/PDM needs evolve to
    include customer or market focusing support. In the early or later stages of a
    lifecycle, informed decisions required unstructured and data from multiple
    sources. Our customers are starting to ask about “granular product content
    networks”. They envision both internal and external content networks. Each
    network will control access to one or more sources, compilation/transform into
    specialized formats, and dynamic publishing/amendment of information, change
    management and distribution. As external information demands increase, internal
    users will mandate one click access to their information and the need to
    publish into more external destinations will increase.

     

    I apologize the
    length of this post but this posting was 20 years in the making. One is
    assumption is information is available in the all the required formats. Based
    on several decades of process industry PDM/PLM experience, we seeing evolution
    in PLM usage and more customers are mandating additional usages of product
    information.

    Even though their system can have 1,000,000’s of
    formulas with associated packaging, labeling, compliance and specification
    information, sales, marketing and supply chain teams cannot easily access the
    required information. Most often, these teams have manual processes to plug the
    gap.

    As the rate of change of formulation change is ramping
    and these teams get slammed and the time to sales enable is increased and risks
    to brand equity is increased. Often, the next formula version is available
    before the previous formula version’s sales enablement is completed.

    Why? One issue is the increasing rate of customer
    requirements. Big retailer/b2b customer are becoming more demanding. Few PLM
    solutions can deal with weekly or even monthly reconfiguration and associated
    change management issues. The second issue will be required increase in
    required data maintenance. If you previous PLM process certified the formula
    and FG spec, adding 10 or more sales teams to the process can significantly
    extend the time to market. While adding these groups to the process is the
    right thing to do, more companies focus on the certification of product and not
    sales enablement. It is easier for PLM to just bypass these two issues and only
    maintain bulk formulas and only Specifications for FG. The result is an
    information gap. As we work with customers, we are creating one or more of
    these product content networks. The network starts with any available PLM or
    enterprise data, consolidates the information into product, channel or customer
    specific information. The network specific processes allow the appropriate
    users to hide and amend information, approve the information, and publish the
    information to multiple destinations. To ensure compliance, we configure the
    PLM to approve the output, write back to PLM or our Product Content application
    and ensure the one version of truth without impacting the traditional PLM users.
    It is a win win!

    While some say “must be a PLM solution issue”, you
    have to understand that one bulk product , “like latex white paint” can be sold
    into 5 or more package sizes, have plant specific or seasonal formulation
    variants, sold as branded and private label in stores and used by other
    manufacturers. At the moment of truth for each buyer and product category, the
    information content and method of delivery is different. With every change to
    formula, you impact 100’s of customer document or data feeds. If you add time
    to your PLM processes to add every unique data usage, you will add significant
    time and this is not politically acceptable. You standard processes can used to
    ensure compliance and update enterprise systems. Product Content Networks put
    the ownership for unique data on the appropriate owners. They have can staff
    the tasks and fund change management requirements.

    One last challenge is that not all SKUs are sold at
    the same rate. With publication rules, we can create data for commonly sold
    information and allow on demand publishing for infrequently used products. To
    make this work, your sales and marketing or customer will continually change
    their requirements. Few PLM or customer can deal associated PLM change
    management.

    Like PPM or new simulaiton applications, we see a new
    category or addon solutions for industyr specific Product Content Network
    applications. For both internal usage and emerging social marketing needs, the
    Product Content Networks will allow you ensure consistency of your product
    information across your internal divisions and external channels. You can drive
    more revenue and protect your brands across multiple channels.

    rory

  5. drewsherlock says:

    Posted this on LinkedIn, but thought I’d put it here as well….

    Jim, interesting paper.  Got lots of thoughts mostly echoing yours, but a few of my own as well ;-)

    Retrieval tools are poor

    Regardless of whether you have PDM/PLM or not, the current tools we have for retrieving data from stores of product data are pretty poor. Things are OK when you want to retrieve items in ‘standard’ ways through part names, descriptions or attributes or by browsing through product structure. But try to get your system to answer an engineering question like ‘which of our stainless steel parts are overpriced – show me all stainless parts ranked by the ratio of price to volume’. The data’s there in your PDM and ERP sytems but can you get at it that way?

    There’s almost never only a single source of information or single type of user.

    Over the last few months I have spent several days sitting next to engineers, and others outside of engineering, being shown how they get at the information they need. It’s fascinating watching them wade through multiple documents (often not electronic), then dive into CAD assemblies to find a particular part, search through PDM systems, cutting and pasting part numbers into ERP systems all in order to get at a particular piece of information. It’s real swivel chair integration.

     Of course, the nature of this journey through the data varies according to what data managament systems you have in place, but there is always a boundary to your PDM/PLM system and some data thats’s not in it. Either it’s unmanaged or handled in ERP, SCM or CRM sytems. As Chad Jackson points out on his blog, http://bit.ly/v4eUl1, engineers have a very broad reach across all the departments and systems in an organisation.

    There’s also not a single type of user. There’s often real benefits to be had by having users in purchasing departments or sales departments, say, be able to access product data, but maybe the PLM and CAD systems don’t reach there because of licensing costs or skill sets of those users. And so these users either have a much harder journey navigating through the data, or they don’t bother and bad decisions are made.

    Retrieve or manage or both

    I have seen a number of companies whose product data (CAD files, document, spreadsheets) has grown quite large and it gets hard to find stuff. PDM is offered as a solution and PDM and/or PLM does a good job at ‘managing’ the data, revision control, ECOs, other workflows etc.. However, in at least some cases, it’s probably not worth the effort and expense to migrate data into the system. But, as you point out, you don’t necessarily have to centralize data in order to make it findable – just crawl and index the data and provide good retrieval tools and it may be good enough.

    Scope for some interesting innovation

    You’ve mentioned a couple of emerging solutions based on existing search technologies (semantic or not). I think these can take you good distance, but I’d argue that the nature of product data is different to the document and textual data most search is oriented towards. There’s more structure and large amounts of data in CAD files describing the geometry of the product to an incredible level of detail which is opaque to these techniques.

    Similarly, designing the UI specifically to display product data (especially where this is associated with 3D objects) can really enhance the effectiveness of the software. Dassualt and Siemens have done some interesting things here with 3D Live and HD-PLM.

    Now the plug…

    We at ShapeSpace have been working with Actify on the search in their new Centro product. Basically, Centro is intended as a way to do 3D product data mashups, pulling data from multiple sources and allowing it to be aggregated, searched and results displayed in a 3D context. See http://bit.ly/vYvwj8 and http://bit.ly/rVPJsu

    Nice thought provoking paper! I think there’s some interesting new ideas to come out of this area in the future.

    • Drew,
      Thanks for pointing out Chad’s post on engineers having a broad view of the business (http://www.engineering-matters.com/2010/12/engineer-broadest-enterprise-reach/), well said. I commented there that products are the center of a manufacturer’s world – meaning that Engineers are at the center of it all. Design for x,y,z,etc. means that companies want to get products right the first time in all aspects (cost, quality, serviceability, supply, environmental compliance, etc.). Engineers (and others in product development, hopefully we have cross-functional teams, right?) need lots of information to do this.

      I love your example about costs. I was about to say that a lot of that cost information is not really in either ERP or PLM (ERP has historical costs which may not be relevant and PLM costing is typically poor, see “Did PLM Give up on Product Cost Management: http://tech-clarity.com/clarityonplm/2010/plm-product-cost-management/). As I kept reading, you mentioned documents and unstructured data. The ugly truth is that there is a lot of cost information in spreadsheets, particularly the kind of estimates that are useful for new components versus steady-state purchasing.

      So the idea of pulling together all of this information is fascinating. Mashing up information from ERP, PLM, and other sources reminds me of the “composite applications” for product management I thought we would see more of by now (I have posted on ERP-PLM integration for some time, and there are some good examples of this). Your point about making poor decisions is exactly the issue – people can’t find the right information so they do the best they can with the time they have available.

      I love the idea of putting product data in the context of the 3D product, whether directly or simply providing both pieces of information.

      Thanks for your post, I look forward to learning more about what you are working on soon.

      Best,
      Jim

  6. drewsherlock says:

    Posted this on LinkedIn, but thought I’d put it here as well….

    Jim, interesting paper.  Got lots of thoughts mostly echoing yours, but a few of my own as well ;-)

    Retrieval tools are poor

    Regardless of whether you have PDM/PLM or not, the current tools we have for retrieving data from stores of product data are pretty poor. Things are OK when you want to retrieve items in ‘standard’ ways through part names, descriptions or attributes or by browsing through product structure. But try to get your system to answer an engineering question like ‘which of our stainless steel parts are overpriced – show me all stainless parts ranked by the ratio of price to volume’. The data’s there in your PDM and ERP sytems but can you get at it that way?

    There’s almost never only a single source of information or single type of user.

    Over the last few months I have spent several days sitting next to engineers, and others outside of engineering, being shown how they get at the information they need. It’s fascinating watching them wade through multiple documents (often not electronic), then dive into CAD assemblies to find a particular part, search through PDM systems, cutting and pasting part numbers into ERP systems all in order to get at a particular piece of information. It’s real swivel chair integration.

     Of course, the nature of this journey through the data varies according to what data managament systems you have in place, but there is always a boundary to your PDM/PLM system and some data thats’s not in it. Either it’s unmanaged or handled in ERP, SCM or CRM sytems. As Chad Jackson points out on his blog, http://bit.ly/v4eUl1, engineers have a very broad reach across all the departments and systems in an organisation.

    There’s also not a single type of user. There’s often real benefits to be had by having users in purchasing departments or sales departments, say, be able to access product data, but maybe the PLM and CAD systems don’t reach there because of licensing costs or skill sets of those users. And so these users either have a much harder journey navigating through the data, or they don’t bother and bad decisions are made.

    Retrieve or manage or both

    I have seen a number of companies whose product data (CAD files, document, spreadsheets) has grown quite large and it gets hard to find stuff. PDM is offered as a solution and PDM and/or PLM does a good job at ‘managing’ the data, revision control, ECOs, other workflows etc.. However, in at least some cases, it’s probably not worth the effort and expense to migrate data into the system. But, as you point out, you don’t necessarily have to centralize data in order to make it findable – just crawl and index the data and provide good retrieval tools and it may be good enough.

    Scope for some interesting innovation

    You’ve mentioned a couple of emerging solutions based on existing search technologies (semantic or not). I think these can take you good distance, but I’d argue that the nature of product data is different to the document and textual data most search is oriented towards. There’s more structure and large amounts of data in CAD files describing the geometry of the product to an incredible level of detail which is opaque to these techniques.

    Similarly, designing the UI specifically to display product data (especially where this is associated with 3D objects) can really enhance the effectiveness of the software. Dassualt and Siemens have done some interesting things here with 3D Live and HD-PLM.

    Now the plug…

    We at ShapeSpace have been working with Actify on the search in their new Centro product. Basically, Centro is intended as a way to do 3D product data mashups, pulling data from multiple sources and allowing it to be aggregated, searched and results displayed in a 3D context. See http://bit.ly/vYvwj8 and http://bit.ly/rVPJsu

    Nice thought provoking paper! I think there’s some interesting new ideas to come out of this area in the future.

    • Drew,
      Thanks for pointing out Chad’s post on engineers having a broad view of the business (http://www.engineering-matters.com/2010/12/engineer-broadest-enterprise-reach/), well said. I commented there that products are the center of a manufacturer’s world – meaning that Engineers are at the center of it all. Design for x,y,z,etc. means that companies want to get products right the first time in all aspects (cost, quality, serviceability, supply, environmental compliance, etc.). Engineers (and others in product development, hopefully we have cross-functional teams, right?) need lots of information to do this.

      I love your example about costs. I was about to say that a lot of that cost information is not really in either ERP or PLM (ERP has historical costs which may not be relevant and PLM costing is typically poor, see “Did PLM Give up on Product Cost Management: http://tech-clarity.com/clarityonplm/2010/plm-product-cost-management/). As I kept reading, you mentioned documents and unstructured data. The ugly truth is that there is a lot of cost information in spreadsheets, particularly the kind of estimates that are useful for new components versus steady-state purchasing.

      So the idea of pulling together all of this information is fascinating. Mashing up information from ERP, PLM, and other sources reminds me of the “composite applications” for product management I thought we would see more of by now (I have posted on ERP-PLM integration for some time, and there are some good examples of this). Your point about making poor decisions is exactly the issue – people can’t find the right information so they do the best they can with the time they have available.

      I love the idea of putting product data in the context of the 3D product, whether directly or simply providing both pieces of information.

      Thanks for your post, I look forward to learning more about what you are working on soon.

      Best,
      Jim

Trackbacks

  1. [...] you had a chance to read Jim Brown’s post, Accessing all your product data regardless of where and how it is stored?  Jim makes an excellent case why data access is so important.  Here are two of my favorite [...]

  2. [...] product data than I ever realized. I was amazed at the discussion generated by my blog post about accessing all product data regardless of how it is stored. In particular, there as a lot of PDA discussion on LinkedIn. For those that can’t access it [...]

  3. [...] you caught the recent article by Jim Brown?  It’s generated lots of commentary on how companies optimize access to product [...]

Speak Your Mind

*