- COBie is a spreadsheet
- COBie uses OmniClass Table 23 “The current edition of "Table 23 - Products" covers almost 7000 products used in the construction and operation of buildings.”
- Organizations are demanding COBie but few actually know what they want from it.
- COBie has been developed in a silo
- COBie does not work with software firms to better integrate with their systems
Now let us take each of these bullets on one by one, granted in the Marine’s I was taught “One Shot, One Kill”, but I’ll play nice in the sandbox here.
COBie at the end of the day is a spreadsheet, words spoken from COBie’s father. Then why do so many think you can’t have BIM without COBie; or that you need BIM for COBie? Why in this day and age with intricate web interfaces and practically every firm using Microsoft Office do we rely on spreadsheets to handle data that should reside in a database? Pretty soon the new COBie will require us to have paper based ledgers to keep track of the model elements. I should mention in here that COBie is actually an xml based information exchange but has been formatted as a spreadsheet for the general use of the AECO industry. While it is a nice attempt at integration it unfortunately is letting people use the wrong tool for the job which actually makes it much harder to be successful. Kind of like using a wrench to hammer a nail; you might get it to work but wouldn't a hammer make more sense?
Okay now to the OmniClass conundrum. First I'll say that I work in a Revit shop, I still haven't found the elusive Open BIM Authoring platform, and that is where my comments to this come from. Why do we need OmniClass table 23 in the design and construct phase? When designing in Revit a wall is an assembly made up of individual parts and components not a whole bunch of parts and components disassociated from it. In the O&M phase of a project will an owner possibly want to know the drywall and studs manufacture; maybe but in this case not a realistic item. Maybe COBie should look at how a building is designed, constructed, and modeled. We should be using table 21. Let’s face it; most owners don't care if a screw was made by xyz corporation or yzk corporation as long as it functions correctly. For unitized items this is useful, but not for system/assembly items.
Increasingly, organizations are demanding COBie for their projects. The first problem is that unless they are using an out of box CAFM or CMMS system with no customization; they will spend months’ worth of man-hours just harvesting the data. I doubt anyone told them that. Then, you have the VA BIM Guide. They want COBie and will tell you how you will build every square inch of your model, but they will VE COBie out the first chance they get. I have also seen where COBie was provided and it went on the virtual shelf because the facilities team said it took too long to implement it. Also anytime a guide needs instructions for the instructions something has failed. Then if the first COBie wasn't hard enough to get your head wrapped around, we have COBie lite, SPie, BIMSie, and now BAMie what’s next? If we're not careful, we're going to wake up to a great big WHAMie one of these days.
COBie was born in (and lives in) a silo. I have seen little if any industry input or challenges with the exception of it being VE’d out of a project. (Wait people challenge COBie all the time, in fact you are challenging it now.) Yes, but was it developed with an industry consensus like other groups have done, USACE/BIM Advisory Committee, VA BIM Advisory Committee, and Penn State? Granted in an ever evolving world, perfection is elusive, yet by including industry, software, and academic experts we can get closer.
So why is COBie foisted upon us all? Simple answer: It was the first carrot for owners to leverage BIM beyond visualization. Working in opposition to software providers, designers, and contractors who are actually putting work in place, and telling them this is what you have to do now is not a wise choice for adoption.
COBie puts on a challenge every year for software providers and developers to show how they can work with COBie. Problem is I have yet to hear software providers talking about how helpful the folks who brought you COBie are to work with. Instead I hear we have to change our software to work with COBie which is ever changing and evolving. Where's the business proposition for the software providers? They are being told they have to change on one side and being told that the thing they are changing to does not work on the other. So do they change to something that is being pushed as what people will want or do they listen to the individuals using their product that say they don't want it? So far it's really somewhere in between.
So is COBie really dead? Not yet. But it needs to stop avoiding the issues of the industry if it does not want to be. Simple solutions can do wonders for COBie. We listed five problems so here are five possible answers:
- Create an open-source project database that users can link their models/data to that will properly communicate with owners CAFM/CMMS products.
- Construct the proper relationship in COBie between products and assemblies that use OmniClass Tables 21 and 23 accordingly.
- Spend more time educating the end users on what COBie is, how they can use it, how they can integrate it in their systems, and how they can require it. The industry does not get it yet. But the most important part here is altering it to fit the way the industry actually practices their work.
- Have consensus groups involved in the answer to #3.
- Give the software companies a business proposition. This part is actually getting closer but is part of a much larger problem. The war between open-BIM and software companies needs to be stopped. They are two sides that need each other to exist and move forward. But that is a post for another day.