So far in this series I've spent most of the time describing the process and critical success factors to capturing good benchmarking data. The end of the last blog however commenced the discussion on how to use this information. Using information stored in databases is often harder than you'd think. Some systems are great at designing efficient ways to consume data but then spend very little time on ways to view what has been captured. When the goal is benchmarking data, the outputs are the most important functional units.
Outputs vary dramatically depending on the users perspective of benchmarking and what they want to use it for. Below is a list of examples that we have encountered over the past four years (how many could you lay your hands on in less than 5 minutes):
And the list goes on...
One of the difficulties in developing systems and processes to cater for all these types of questions is in the design of the report engine. Some of the questions are impossible to answer via a generic report interface (e.g. the parametric pricing model used for number 9 above). But most can be answered via the design of a simple to use data analytic tool and a well designed business intelligence cube. We've used the following interface options to present data captured into our BI cube:
A possible alternative to the bespoke web applications, which can be expensive to build, maintain and expand on would be the use of SharePoint's integration with Analysis Services (which is what our BI cube is built on).
I guess the biggest lesson learnt from this space is that you should get as long a list of desired outputs as possible as soon as possible to assist in preparing an overarching architecture that can support what will ultimately be a variety of interfaces into the data.
Outputs vary dramatically depending on the users perspective of benchmarking and what they want to use it for. Below is a list of examples that we have encountered over the past four years (how many could you lay your hands on in less than 5 minutes):
- Show me the average elemental rates for particular sectors, project types, asset types and work types for a particular location or across locations
- Using the same function, show me the average trade rates over the past 12 months in a specific location to update a rate library in a cost planning tool
- Display average USD/SF GFA rates as a bar chart for particular sectors, project types, asset types and work types for a particular location or across locations
- Map the range of wall to floor ratios for selected filters
- List architects from most expensive to cheapest for average new builds in commercial office towers in London using a £/SF rate of GFA for construction costs.
- List the top 10 most expensive museums on a USD/SF of GFA basis across the US in the past 10 years. Show me their design characteristics and functional units (e.g. excavation required, area per floor, no. of levels, no. of rooms etc)
- Show on a map where my projects have been and change the size of the circle to reflect the cost of the project
- What's the average time to reach final account on a commercial new build project costing more than $20m and lasting longer the 6 months?
- Using past projects, price a new project for me in this location for a new build industrial factory with 10,000 sqm of floor space.
- Utilise past projects to phase my new one
And the list goes on...
One of the difficulties in developing systems and processes to cater for all these types of questions is in the design of the report engine. Some of the questions are impossible to answer via a generic report interface (e.g. the parametric pricing model used for number 9 above). But most can be answered via the design of a simple to use data analytic tool and a well designed business intelligence cube. We've used the following interface options to present data captured into our BI cube:
- Bespoke web applications
- Excel
- Tableau
- Proprietary Android native apps
- Proprietary iOS native apps
A possible alternative to the bespoke web applications, which can be expensive to build, maintain and expand on would be the use of SharePoint's integration with Analysis Services (which is what our BI cube is built on).
I guess the biggest lesson learnt from this space is that you should get as long a list of desired outputs as possible as soon as possible to assist in preparing an overarching architecture that can support what will ultimately be a variety of interfaces into the data.
If you're interested in how UniPhi's software can help you benchmark and get the outputs you want contact us
No comments:
Post a Comment