Hierarchical Templates

The Strategic Advantage of BuilderChain’s Hierarchical Templates

In the complex and fast-paced world of construction, the ability to standardize processes while maintaining flexibility is crucial for success. BuilderChain’s hierarchical templates offer a powerful solution, providing a structured yet adaptable framework that allows construction companies to optimize every aspect of their operations. By integrating these templates with BuilderChain’s ontology, BuilderPay’s financial automation, and Palantir’s advanced analytics, businesses can achieve a new level of operational excellence.

The Power of Hierarchical Templates in Construction

Management Hierarchical templates are the backbone of BuilderChain’s approach to construction management. They provide a multi-layered structure that organizes tasks, processes, and workflows into a coherent, scalable system. These templates allow construction teams to build upon pre-defined frameworks that can be customized to meet the specific needs of any project, ensuring consistency and efficiency across the board.

At their core, hierarchical templates are designed to bring order and clarity to the often chaotic environment of construction. They break down complex projects into manageable components, each with its own set of tasks and dependencies. This structured approach not only ensures that every detail is accounted for but also provides a clear roadmap for project execution, reducing the risk of errors and delays.

Integrating Hierarchical Templates with BuilderChain’s Ontology

BuilderChain’s ontology-based platform takes the power of hierarchical templates to the next level. The ontology serves as a dynamic, interconnected framework that understands the relationships and dependencies between every element of your business. When hierarchical templates are integrated into this ontology, they become more than just static frameworks—they become living systems that adapt and respond to real-time data.

Hierarchical Base Templates

To drive the highest level of efficiencies along with consistent data application, the use of hierarchical data structure is deployed to achieve those objectives. This starts from the most abstracted form of project data and that would be BIM data derived from modern day CAD applications. That data represents the abstracted material objects without reference to manufacturer, vendor, or pricing at this stage.

Both Primary and Secondary Bill of Materials (or Take-offs) are combined to create site specific BOM

Hierarchical Option Templates

Even the options structure takes full advantage of Hierarchical Inheritance.

Sales Option & Production Option Templates

One type of use of this data structure is like the hierarchical use we applied for subdivision homebuilding. In this case, we used the Company-wide BOM Template and the Subdivision-wide BOM to assign all materials and labor that was common to every lot specific project.

Inheritance

Although our estimating technique is quite powerful when employed at the Design Takeoff level, its real power is realized when utilizing a hierarchical data structure. Let’s look at how inheritance is used to leverage our estimating technique to its full potential.

Although our estimating technique is quite powerful when employed at the Design Takeoff level, its real power is realized when utilizing a hierarchical data structure. Let’s look at how inheritance is used to leverage our estimating technique to its full potential.

Political, Non-Political and Organizational Boundaries

Network Inheritance

Political, Non-Political and Organizational BoundariesPlan specific takeoffs can be provided from many different sources, either at the architect level, builder level, or the vendor level.

Since takeoffs are assigned our patent pending “Resource Objects”, the process is significantly more efficient since no qualitative characteristics will need to be considered for a takeoff that utilizes our estimating technique.

The most efficient takeoff from a data entry/maintenance standpoint is when the architect provides the takeoff on a per plan design. When the architect provides the takeoff for their plan design, the estimate and bidding process reflects a common set of assumptions regarding quantities and specification levels.

Thus, a more objective and fair basis is maintained for a group of builders and subcontractors that may be participating in the bidding process.

Takeoff Inheritance

Architect to Builder Inheritance

Next we will examine how the builder or builders may take advantage of the takeoff. In one scenario, the takeoff is provided by the architect. In the second scenario, the takeoff is not provided by the architect, so now a builder may be required to generate his own.

In the first scenario, a builder will access the marketplace cloud, browse for available plans, and prior to purchasing the plan, inherit a plan with its takeoff into his system.

Since inheritance is employed, he may benefit from the plan takeoff provided by the architect, but still to elect to override or supplement any resources and/or quantities at his discretion. This is an important feature that provides the builder with an estimate that is optimized specifically for his company’s bid, while maintaining the ability to utilize as much inherited data as possible from the “architect provided” takeoff.

Vendor to Builder Inheritance

This same hierarchical approach is used between the builder (general contractor) and the vendor (subcontractor and material supplier). The vendor may elect to inherit and use the architect provided takeoff, may inherit a builder provided takeoff (if builder flagged to allow), or the vendor might use only his takeoff or supplement his takeoff with another.

This same hierarchical approach is used between the builder (general contractor) and the vendor (subcontractor and material supplier). The vendor may elect to inherit and use the architect provided takeoff, may inherit a builder provided takeoff (if builder flagged to allow), or the vendor might use only his takeoff or supplement his takeoff with another.

Architects that do provide takeoffs, something that has become more common with object oriented CAD systems, create a unique opportunity for the consumer of these resources to realize what a potential project costs will be, specific to the specification levels and vendors they would assign to a project. By integrating all three primary players; architects, builders, and vendors into one integrated environment, instantaneous costs are provided. Let’s see how that works.

Vendor to Manufacturer Inheritance

This same hierarchical approach is used between the vendor and the manufacturer or subcontractor supplier. The manufacturer may elect to inherit and use the architect provided takeoff, may inherit a vendor provided takeoff (if vendor flagged to allow). Or the vendor might use only his takeoff or supplement his takeoff with another. Since the vendor is also using object resources for his takeoff, the process is both streamlined and readily modifiable.

Resource Inheritance

Resource Specification Inheritance

Resource Specification levels can be assigned to the Project, thus allowing an higher level of estimating efficiency. Resource Specification levels can also be assigned to the Subdivision, thus allowing an even more higher level of estimating efficiency.

Changing a Resource Specification level for a particular Project Estimate does provide enhanced capability. The ability to assign these Resource Specifications at a higher level, such as the subdivision level can bring a profound impact on a builder’s ability to respond quickly to changing market conditions by minimizing data maintenance in addition to improved accuracy when these changing market conditions present themselves.

Let’s now illustrate in the diagram (Resource Specification Assignment Hierarchy) below how specification classes can be assigned in a hierarchical manner. Hierarchical assignment allows for “Resource Specifications” to be assigned at their most efficient level, with only the exceptions being assigned at lower levels as appropriate.

The hierarchy on the left side of the diagram reflects how “Specification Classes”, typically discretionary, can be set company, subdivision, lot level, where the hierarchy on the right side of the diagram reflects “Specification Classes” can be set to accommodate geographic requirements, either building code requirements, or certain building practices that may be required in various locations.

Also note that “Resource Specifications” can be flagged as a minimum specification level, or assigned a specification level that would allow “Resource Specification” to be appreciated or depreciated. A “Resource Specification” may also be flagged as absolute, not allowing any changes assigned at a lower level. Take the example of an architect or project owner setting minimum specification levels solely at the “project level”.

This way, alternate pricing scenarios would be subject to those minimum specification levels established by the architect or project owner. And should the minimum specification level set by the architect or project owner not meet a building code requirement based on the location assigned to that project, the specification level required by building code would supersede any minimum level set at any other levels. Any specification levels set electively at an appreciated level would still be applied.

Design Plan Inheritance

Design Takeoff inheritance is provided for within the platform design. The Design Takeoff has been around in legacy software for many years. If there is a Design Takeoff element that is specific to a particular Design Plan, then that Design Takeoff element is built at the plan level. For example, kitchen cabinets will typically be plan specific, taking into account the size dimensions of the kitchen for that Design Plan.

How about the appliance package that may be assigned? Do we need to define an appliance package for every Design Plan when the same package is used, throughout the subdivision across all Design Plans? No. It is considerably more efficient to build the appliance package once, let’s say at the subdivision level, and have it serve all plan designs in that subdivision through the use of inheritance. The inheritance structure available to is illustrated in the Inheritance Flow diagram found below.

Design Plan Assignment is provided for within the platform design. Design Plan Assignment determines which Design Plan is available for sale and approved to be built, specific to its assignment level.

Although assigning a Design Plan is a simple exercise, Design Plan Assignment via a hierarchical structure does provide an improvement in the maintenance of these assignments. Design Plans can be assigned at the company level, the subdivision, or even down to the lot level when necessary.

Design Option Inheritance

The key difference in using Resource Specification change is that it is done without regard to quantities or what activities those resources may be found. Options require finding where the resource targeted for change is located and optioning out the old resource with the new resource, one resource at a time, being sure to set the quantity in the option the same.

Resource Specification changes happen without having to drill down into the Plan Takeoff. Resource Specifications do not change quantities, only Options do. The key difference in using Resource Specification change is that it is done without regard to quantities or what activities those resources may be found.

But when a scenario is presented where a change in the project scope and quantity changes are needed, then Options must be employed. What is unique in our product design is the use of inheritance to define and maintain Options.

If there is an Option that is specific to a particular Design Plan, then that Option is built at the plan level. For example, a bonus room over garage will typically be “plan-specific” taking into account the dimensions of the garage for that Design Plan. But how about adding an electrical outlet? Does an “electrical outlet option” need to be defined for every Design Plan?

No. It is considerably more efficient to build the “Add 110 volt Electric Outlet” Option at the company level, and have it serve all plans in all subdivisions through the use of inheritance. Likewise, Option Pricing is easily maintained once at the company level.

Should you need to have a different price in one subdivision, that adjustment is accomplished by creating a price exception for that one subdivision and letting all other subdivisions derive their price from the company level pricing. The inheritance structure available to use is represented in diagram found below.

Design Option Assignment inheritance is provided for within the platform design. Design Option Assignment determines which Option is available for sale and approved to be built, specific to its assignment level. Design Options can be assigned at the company level, the subdivision, or even down to the lot level when necessary.

Vendor Inheritance

Vendor pricing inheritance is also provided for within the platform design. In this case, a vendor can have a price established specific to the marketplace that is available to use across all participants in the marketplace.

Vendor Data created and published can be either Public or Private.

But sometimes, a vendor may want to assign private pricing for a specific builder or general contractor or assign a specific price to a particular location a project may be located in due to delivery issues or other factors such as theft.

In this case, a vendor can assign their marketplace price with the knowledge that a particular general contractor or builder may realize private pricing. And should a project be located in a particular location, the vendor can also be assured that any location dependent pricing has also been accommodated.

Vendor Assignment inheritance is provided for within the platform design. Vendor Assignment determines which Vendor is assigned to a Resource Class (such as Windows Group), specific to its assignment level. Once a Vendor has been assigned, any estimates or purchase orders awarded will utilize that Vendor Assignment.

Although assigning Vendors is a simple exercise, allowing Vendor Assignment via a hierarchical structure does provide efficient maintenance of these assignments. Vendors can be assigned at the company level, the subdivision, or even down to the lot level when necessary.

Although not a common requirement, the Location Hierarchy can also be used for Vendor Assignment when it proves more efficient.

Code Jurisdiction Inheritance

Another complex issue that must be taken into account in arriving at a project’s true cost is the building code requirements for that project based on its location. When various building code requirements impact projects with multiple locations, applying the correct resources can be daunting.

With the application of “Resource Specification” assignment and “Production Options”, any building code requirements are automatically addressed. Again, the goal of our platform design is to reduce these complexities to be transparent when the marketplace is utilized.

Tax Jurisdiction Inheritance

Another complex issue that must be taken into account in arriving at a project’s true cost is the taxing district a project may be located. But the applicable sales tax rules may also be impacted by the location of the vendor’s primary business in lieu of, or in conjunction with a project’s location. When various projects with multiple vendors interact, applying the correct taxing methodology can be daunting.

Again, the goal of our platform design is to reduce these complexities to one click control. Much like the application of Resource Specifications to building code jurisdictions, tax rules are now applied to the marketplace, taking into account the location of the project.

And when the location of a vendor’s primary business may impact that sales tax rate, it is seamlessly applied automatically when that particular vendor is assigned to a project. This is important when one vendor is quoting on a project may be lower but when his primary business location creates a higher taxing rate this is taken fully into account.

The inheritance structure available to use would be the same as defined for use by the Resource Specifications as illustrated in the Inheritance Flow diagram found in the next slide, but typically limited to the right side to the diagram that reflects the location inheritance flow.

Inheritance Use Case Scenario

Six months into the subdivision development a competitor opens his subdivision development across the street. The competitor is offering a better grade window than our builder used during his initial estimates. To respond to his competitor, he now feels the need to change the grade level of all his windows for all the plan designs offered in this subdivision development.

If the Builder is offering ten different Design Plans per subdivision, and each plan has approximately eight different window sizes per Plan Design that are impacted by a specification change, traditional approaches would require that eighty different windows resources would need to be modified.

When you compare past methodologies to a “one click” specification change at the subdivision level when our estimating technique is employed, the ability for the builder to respond quickly to market changes is greatly enhanced.

Company-Wide Use Case Scenario

Another scenario is when “Resource Specifications” are assigned to the company level. Assigning specification classes at a company level allows for various grade levels to be quickly assigned, one time at the company level, when those grade levels are common across all subdivision developments. This can be employed as a minimum specification grade that is assigned as a company policy.

And since inheritance is employed natively at the platform level, any Resource Specifications assigned at either the subdivision development or the Design Takeoff level will override any setting at the company level; when that Resource Specification represents a change from the company Resource Specification assignment.

For example, our builder is building in ten subdivision developments. Each of those subdivision developments include ten different Design Plans per subdivision. In this scenario, a change of a specification grade at the company level could potentially impact over 800 window Resources across all plan designs in all subdivision developments (10 subdivisions x 10 plans x 8 resources per plan design).

Current takeoff/estimating approaches can make this a particularly arduous task. Using our patent pending estimating technique, all 800 resources can now be changed using our one click assignment of a Resource Specification at the company level.

Code Requirements Use Case Scenario

Minimum “Resource Specifications” can also be assigned to a particular location, such as town or municipality, based on local building code requirements. Here we have a need to make sure that any building code requirements are taken fully into account when producing estimates for a given subdivision development based on its location.

In this example, again our builder has ten separate subdivision developments, but three subdivisions are in one building code jurisdiction, four subdivisions are in another building code jurisdiction, two in another building code jurisdiction, and one in its own building code jurisdiction.

When these subdivision developments are assigned to their appropriate code jurisdiction via its location, the minimum “Resource Specifications” that are assigned to the building code jurisdiction are applied.

Now each subdivision development can rest assure that the right specifications are used based on any building code requirements for that building code jurisdiction. And the relevant specification requirements are maintained at the marketplace location only once for the building code jurisdiction instead at either the plan takeoff or subdivision level.

Once our estimator begins a takeoff, he doesn’t even need to take into account any building code jurisdiction requirements since this will be accomplished via “Resource Specifications” assigned at the building code jurisdiction level. If a building code jurisdiction decides to change a specification requirement, it is handled much more efficiently at the building code jurisdiction level versus finding and modifying any products that may be impacted using traditional takeoff/estimating approaches.

Object Resource Governance

As the centralized control mechanism, the marketplace defines all “Object Resources”. These resources must be common across all participants in the marketplace. This is a key element and critical feature that drives the unique value of the marketplace.

Products produced by national manufacturers are assigned their appropriate “Object Resource” and maintained at the marketplace. They are exposed into the marketplace for a fee. Vendors then inherit a “manufactured product” they are authorized to sale, and then assign a price for the marketplace.

The vendor may also offer their own product, service, or turnkey bid to the marketplace, being sure to assign the correct object resource that will drive the automated bidding process of the marketplace.

The marketplace also assigns the specification class to each of these nationally manufactured products, those controlling how the default products are presented. These “Specification Classes” allow the marketplace to assign an “or equal” product across different manufacturers.

Although this “Specification Class” will present the default “or equal products”, there remains the option to override the product assigned at the builder or vendor level. But the first default value for the automated project estimate across all products and all vendors will be the “Specification Classes” as assigned by the marketplace. This also creates a unique advantage to the marketplace value.

One Off Projects

In the previous examples the benefits have been focused on the production based builder, operating in a multiple plan design, multiple subdivision development environment.

General contractors bidding and working on commercial projects or the custom homebuilder that creates a unique home for each project, may not realize as much efficiency gains as the large scale production homebuilder. But the unique ability to produce a takeoff without the consideration of specifying the qualitative products is a significant advantage for both the general contractor and the project owner.

Let’s take the example of a project owner that has a custom home they would like a price bid from a custom homebuilder, although the same would apply for the general contractor bidding on a commercial project. Since most plan designers do not provide a specification documents for custom homes, it is hard for the project owner to receive an “apples to apples” comparison from one general contractor to the next.

Typically, the custom homebuilder will need to go through a long list of what specification levels the project owner may want or the custom homebuilder will just “wing it” using some specification they think should be used or will give him a competitive bid advantage over the other bidders without the project owner being aware.

The custom homebuilder will likely need to send the drawings out for bids from the various subcontractors before an accurate bid can be provided to the project owner. This process can take days or weeks, with many potential ambiguities that may be incorporated in any bid provided.

Using our patent pending estimating technique, a custom homebuilder, and/or the required subcontractor can now takeoff only the “object resource”, without the arduous requirement of selecting the specification level of each and every resource for the project. be compiled.

And since this process takes place over the web using one unified platform for both the custom homebuilder and any subcontractor solicited to bid on the project, a much faster and accurate takeoff can be compiled.

Once the project owner returns to the custom homebuilder to review the bid, any assumed specification classes assigned can be easily and quickly changed using a “one click” approach so that project bids can be adjusted up or down until the optimum project costs are arrived.

The builder or general contractor can create their own “markup rules”, thus allowing for both percentage and dollar markups to be compiled. Markup rules can also be targeted at different resources in the project, allowing some items included in the project estimate to be marked up at higher rates than others.

Conclusion

Although the takeoff, estimating and bidding process is quite complex, we believe our platform design provides for the most efficient and effective way to execute this process. Such that the efficiency gains are so significant, we believe the adoption rate will be very high.

By offering our platform as a cloud based solution, customers will not require anything more than a computer and internet access to participate. We see two potential revenue streams for our platform. Entry and use of the system will be free with only a transaction charge to the vendor and/or builder once a Project starts and transactions commence.

The other revenue stream will be the use of context specific advertising; very carefully targeted at a builder or general contractor while making the very purchasing decisions where that context based ad is displayed. This provides vendors a unique way to display their message at the most critical time of the decision making process.

There is a phase two of the marketplace that is planned that will increase functionality by leveraging the data as it exists in the marketplace, utilizing its unique Blockchain environment through inheritance.