Jose Fandos of Andekan wrote an interesting post yesterday that offers his insight into Shared Parameters and content for manufacturer's. His post is called: Shared Parameter Standards Part 2 - What's a Manufacturer to Do? (You can read his Shared Parameter Standards - Part 1)
His position should be interesting to a variety of folks who have been trying to get some standards developed. Boiled down he writes:
...snip
"manufacturers shouldn't add any shared parameters to their families. Instead they should include family parameters for every piece of information most of their users within the AEC industry might want to use within a project."
...snip
I can relate to his position. All you have to do is sit down with a couple engineers and ask them what should be in a schedule for VAV HVAC equipment or air handlers, or boilers. Doesn't even have to be engineers from different offices...same office will work often enough. The result? Different expectations. Implementation for content at a firm (at least with MEP/F) usually works best if scheduling requirements are defined early. Imagine making/tweaking a lot of content only to find out there is this whole other pile of information we really want to schedule?
So the issue that Jose is digging at is how does a manufacturer get content built now? Considering one firm may not be able to agree on what should be in their schedule, let alone 10 firms agreeing on a "standard". When will this standard be available to them? What about the proprietary information they have that they provide in schedules on "cut-sheets" for product data?
Messy, messy... no wonder it isn't resolved already!?!
Perhaps we should examine why a schedule exists to begin with? Why does an engineer create a schedule of information for a boiler in the first place? To be highly specific or define criteria that contractors need to meet as a minimum design specification? In the competitive bidding process for projects a engineer usually can't even insist on a specific product unless an "or equal" doesn't exist.
Even if HP (horsepower) is a legitimate value to schedule for our boiler's fan and pump what typically happens is manufacturer A uses "HP Fan" and manufacturer B uses "Fan HP" while manufacturer C uses "Fan Horsepower". All three are the "same" information but Revit doesn't see it that way. If they aren't Shared Parameters you can't even use them in a schedule anyway. No mapping strategy to tell Revit they are really the same thing, short of customizing all of them yourself.
Perhaps Autodesk needs to have a fresh look at how all this similar/related data can be assembled together into familiar reporting formats, like schedules so we don't have to? It's complex and we need a solution. Perhaps an external database tool like Codebook is the answer ultimately?
Read his post and weigh in!
His position should be interesting to a variety of folks who have been trying to get some standards developed. Boiled down he writes:
...snip
"manufacturers shouldn't add any shared parameters to their families. Instead they should include family parameters for every piece of information most of their users within the AEC industry might want to use within a project."
...snip
I can relate to his position. All you have to do is sit down with a couple engineers and ask them what should be in a schedule for VAV HVAC equipment or air handlers, or boilers. Doesn't even have to be engineers from different offices...same office will work often enough. The result? Different expectations. Implementation for content at a firm (at least with MEP/F) usually works best if scheduling requirements are defined early. Imagine making/tweaking a lot of content only to find out there is this whole other pile of information we really want to schedule?
So the issue that Jose is digging at is how does a manufacturer get content built now? Considering one firm may not be able to agree on what should be in their schedule, let alone 10 firms agreeing on a "standard". When will this standard be available to them? What about the proprietary information they have that they provide in schedules on "cut-sheets" for product data?
Messy, messy... no wonder it isn't resolved already!?!
Perhaps we should examine why a schedule exists to begin with? Why does an engineer create a schedule of information for a boiler in the first place? To be highly specific or define criteria that contractors need to meet as a minimum design specification? In the competitive bidding process for projects a engineer usually can't even insist on a specific product unless an "or equal" doesn't exist.
Even if HP (horsepower) is a legitimate value to schedule for our boiler's fan and pump what typically happens is manufacturer A uses "HP Fan" and manufacturer B uses "Fan HP" while manufacturer C uses "Fan Horsepower". All three are the "same" information but Revit doesn't see it that way. If they aren't Shared Parameters you can't even use them in a schedule anyway. No mapping strategy to tell Revit they are really the same thing, short of customizing all of them yourself.
Perhaps Autodesk needs to have a fresh look at how all this similar/related data can be assembled together into familiar reporting formats, like schedules so we don't have to? It's complex and we need a solution. Perhaps an external database tool like Codebook is the answer ultimately?
Read his post and weigh in!
No comments:
Post a Comment