Tuesday
Is this article worthy of discussion, along with the question of diminishing returns in maturing software development vs the corporate mandate for growth... ?
Tuesday
Isn't the typical architectural model is still pretty generic, and open to interpretation at the building phase?
My feeling is that it is the clients and in some cases construction companies and public officials that ask for higher detail and granularity of data for costing, simulation, manufacturing and permitting etc., not so much the software companies?
In the case of MEP and engineering this may be somewhat different, but there exist a number of approaches to more just-in-time design.
For architects, the current trend in BIM right now looks to be more and more intelligent/automated management of the design, which precisely facilitates the quick turnaround when reacting to change requests / developing detail. Which developments in detail do you see causing issues?
Tuesday
This comment seemed notable:
"For the remaining 70-80% of projects, particularly smaller developments with limited budgets, tight timelines, or minimal technical expertise, BIM's complexity may outweigh its benefits"
Tuesday
Yes, some edge cases probably can have trouble realizing a lot of the benefits in BIM.
Still, my experience is that even the small projects add up, and having accurate documentation (where BIM should really excel) will be valuable, at least in the long run, to the owner of the building. Having said that, the real digital twin side of BIM, ie. use in maintenance and operation, is still a little underdeveloped.
Small/simple projects, where the benefits of repetition and scaling can't be realized, probably need to consider the detail level that BIM will be executed at. But on the other hand, a lot of AI tools seem to be coming to the rescue, offering ways to create models from photography, classifying and refining approximated models into usable ones and so on, lessening the manual detail work. Particularly on small projects the required checking and guidance by humans is very feasible (as opposed to large complex projects, where it can be overwhelming), so maybe there's some hope.
Tuesday
"BIM requires that every detail be finalized before construction begins, from electrical switch locations to final finishes."
As soon as I read this - that's where I stopped.
BIM is so much more than just modeling - but this article seems to focus only on that, modeling.
If the organisations don't adapt to BIM then of course it won't work. BIM is not only the model - but often mistaken for just that, because that is what you see.
Tuesday - last edited Tuesday
@Erik Bjornhage wrote:
BIM is so much more than just modeling - but this article seems to focus only on that, modeling.
If the organisations don't adapt to BIM then of course it won't work. BIM is not only the model - but often mistaken for just that, because that is what you see.
Absolutely @Erik Bjornhage BIM is essentially about Better, seamless, integrated, early, continued COMMUNICATION by Everyone involved.
https://www.youtube.com/watch?v=2QewPwxRCGU(from my 2023 conference talk)
18 hours ago
Hi Erik,
I too noted that statement, and ask if there are many shades of grey there...
It is easy to race into a schematics with blocked out assumptions, or perhaps with some favourites - is one trap then the need to go back and revise so much when things are changed, or assumptions may not meet the downstream requirements ?
When I launched in to the new options feature in 28 (hence my ask if the relevant to discussion of new features in 29 and potential increasing complexity in general) at the schematic stage I could not anticipate the downstream management needed and how it could affect output especially when options were changed or deleted. I've managed options for decades simply setting up layer combinations in more of a direct and transparent analogue methodology including groups and a layer for hidden groups vs what I liken to a many to many to many relational database approach.
How do new features balance unanticipated overhead in other areas ?
As the article seems to ask does BIM risk developing itself beyond relevance if complexity overwhelms ease of use ?
Are customer interests are being served in such a scenario...?
Is it worth moving to the corporate earnings call transcript to try and understand the current logic and how Nemetschek is considering serving customers...?
https://seekingalpha.com/article/4769603-Nemetschek-se-nemtf-q4-2024-earnings-call-transcript
“In DOPT also beginning of this year selling Perpetual license for new customers at Graphisoft and existing customers have until the end of this year to buy perpetual license. Our plan is also accelerating its migration subscription business model. While we will feel the temporary accounting-related impact at the individual brand level in the Design segment, the impact segment and especially at group level will however be very digestible.
One of the advantages of our brand setup is that we can migrate our portfolio in a phased and segmented approach. This does not only give us substantially more control over the entire transition process, thus significantly reducing the associated risk. It also makes the migration more easily digestible for our customers and users as well as for our shareholders.
Furthermore, it allows us to have individual subscription strategy for each of our segments that is tailored to their specific characteristics. As a result, transition is differently far advanced in all four segments. For example, migration of our media segment is already completed for quite some time with a subscription revenue share of around 59%.
To leave us the Design segments where we have now also a high portion of recurring revenues at around 80%. In addition, we will significantly accelerate the segment's transition to subscription and sales models in 2025 with the ongoing and already well-advanced transition of Vectorworks."
Tuesday
- last edited
Tuesday
by
Laszlo Nagy
@March_ Bruce I believe, though this forum is intended for feedback from user review of the functionality of Archicad 29 Tech Preview in particular, discussion of this article could be relevant, even if only in a broader sense, to the general approach & direction of the development of Archicad & any BIM solutions for our industry.
I am sure Graphisoft's leadership has a good & deep sense of BIM in general, as well as what the complete spectrum of specific tools & functionality that all Archicad users need from our software. Sure, the success & sustainability of the company is a curtail component of this "story", to ensure long term sustainability for the company & effectively for all it's current & future users.
Yes, many of us are users of the software for 40 / 30 / 20 years, some of us are / were local "Resellers" / "Distributors" for Graphisoft supporting other users in our regions, others is / was accredited "Trainers" of Archicad, some of us are Insider Panel Members having the privilege of working directly with Graphisoft's development teams and influencing & informing the development of the next 2-3 versions of Archicad. All this insight has absolute value in what Graphisoft must translate into relevant software, evolving with every version.
Still we can't see or know everything from our somewhat bias perspective as Architects, Designers & BIM Practitioners. We can participate in various ways to contribute to the Graphisoft team's collective insight & innovation.
Somehow all this has to come together in "one place" every year.
I trust / hope this discussion will be moved to the general forum when the Tech Preview closes (moderator: topic moved), as this is an ever evolving endeavor for us all, including Graphisoft.
Wednesday - last edited yesterday
Interesting topic. I agree with people here that BIM is not just modelling, I dare to say that BIM is actually a set of processes. The problem is that BIM affects a very long chain of involved participants and ultimately the beneficiary is the user of the final product (eg the building). That's where the money is (building lifecycle expenditure is disproportionally distributed to burden the product owner/user... 8% design&build / 91% building running cost / 1% demolition). Any available BIM standards were conceived to address the building running cost and not design. Just a few comments from the historical point of view - the UK standard PAS 1192:2011 (forerunner of ISO 19650) was conceived to save UK Government's money for running their newly-built assets (thus the UK BIM Mandate). In reality it meant that the government didn't really care how the design segment would get there as long as they provide structured data for contract procurement and FM (thus adopting COBie - a rather primitive approach however set up as the lowest common denominator for the industry full of laggards). The point here is that the standards focus on deliverables with a great deal of design process trivialisation. The hope was that BIM authoring tools will follow and "fill in" the gaps with functionality and features that would replace traditional concepts. Well, it is easier said than done. I am not trying to use this argument as an excuse for AC development, but I think that initial expectations were rather a toll order which created massive bottlenecks in the design segment along the whole process... starting with licensing costs of new software / hardware, upskilling, uneven adoption in various professions and ending with unpreparedness of design segment's clients, authorities and legal framework (mind you that eg US doesn't have any formal, let alone comprehensive BIM standard...). I guess, the staged approach should have been applied with standards tackling the basic realities of design process, and set up goals that are commercially viable for that segment first. Instead we ended up with an illusively tempting "silver bullet"-like solutions eg IFC that has very high entry threshold for a user, it allows for "deliberate sabotaging" its capabilities by software vendors and its standardisation is driven by "enthusiasts" (respectfully meant).
yesterday - last edited yesterday
Oh! thanks for this deep & profound perspective @Rob
The way you unpack, especially on the origins of UK BIM Standards vs general BIM adoption vs authoring software development vs adoption in the design field is insightful. I want to read this a few times over. Thanks for joining this conversation.
yesterday - last edited yesterday
just a follow up on my previous post to stick with the original topic's name "Barriers to BIM...?" the answer is: there is still a plenty. I will talk here as an architect which is my original profession.
so I am not sure where we should start... 🙂
yesterday
@Rob wrote:
so I am not sure where we should start... 🙂
You answered you own question @Rob, at least for Graphisoft. Start with the "designers, engineers, architects" and ensure Archicad is not "too risky, unpredictable and expensive". You know as well as anyone that even after all this time we are not there yet.
12 hours ago - last edited 12 hours ago
@SeaGeoff long time no speak matey... I hope all is good at your end.
hehe, a bit cheeky but I get your point. There is a bigger problem when you look at it in BIM context though... your suggestion would be valid some decade ago in times of "lonely BIM". Today, the expectations and industry are moving from monolithic BIM authoring tools to the.environment of specialised tools... Martyn Day (AEC Magazine) coined the term BIM 2.0 at NXT BLD Conference in London this year. I am afraid that it is not just GS that should deliver to make this journey smooth(er).
3 hours ago
Hi @Rob. Things are pretty well here if you ignore politics, and pretty sh*tty if you don't. Hope things are calmer in UK.
@Rob wrote:
I am afraid that it is not just GS that should deliver to make this journey smooth(er).
No argument there, but Archicad is the arena where we (you more than I) have some influence. So let's start here and do what we can.
You can only simplify a complex process so much, but we can make it reliable, predictable, and logical. And professional software will never be cheap, but we can make it a good value.