Dokonalá šablona pro Revit neexistuje

Návrh šablony Revit je mnohem víc než jen počáteční soubor

Vytvoření šablony Revit je často vnímáno jako čistě technický úkol: definování pohledů, načítání rodin, vytváření výkazů, nastavení grafických stylů a konfigurace několika parametrů před předáním souboru .RTE týmům.

V praxi je však tento pohled příliš úzký.

Šablona Revit tvoří základ produkčního prostředí. Přímo ovlivňuje způsob, jakým uživatelé modelují, vytvářejí dokumentaci, vyhledávají informace, připravují výstupy a v konečném důsledku v průběhu času rozvíjejí své projekty. Návrh šablony proto zahrnuje mnohem více než několik nastavení softwaru: vyžaduje pochopení pracovních postupů, předvídání potřeb, zvážení různých řešení a vytvoření prostředí, které je dostatečně strukturované, aniž by bylo příliš omezující.

Nalezení správné rovnováhy mezi bohatostí a jednoduchostí

Jednou z prvních výzev je určit, co by mělo být skutečně součástí šablony.

Je lákavé načíst co nejvíce rodin, materiálů, filtrů, šablon pohledů a konfigurací, aby bylo možné pokrýt každý možný případ. Tento přístup vytváří dojem kompletního prostředí, ale může se rychle stát kontraproduktivním.

Přeplněná šablona zvyšuje počet prvků dostupných ve výběrových seznamech, ztěžuje vyhledávání, zvětšuje soubor a činí celý systém obtížněji srozumitelným.

Naopak příliš jednoduchá šablona nutí uživatele neustále znovu vytvářet stejné prvky, čímž se oslabuje značná část přínosu standardizace.

Nalezení správné úrovně obsahu je proto jednou z klíčových výzev projektu.

Právě to mimo jiné vede k rozlišení mezi produkční šablonou a doplňkovými knihovnami: první obsahuje prvky, které se skutečně opakovaně používají, zatímco druhé umožňují udržovat širší knihovnu, kterou lze snadno procházet a rozšiřovat.

Budování knihovny namísto hromadění rodin

Kvalita knihovny Revit nezávisí pouze na počtu dostupných rodin.

Skutečná knihovna musí umožňovat rychle najít správný prvek, pochopit, jak se používá, identifikovat jeho varianty a znát konvence, které s ním souvisejí.

Otázka pojmenování se proto stává zásadní.

Měly by být upřednostňovány popisné názvy? Kódovací systém? Zkratky? Kombinace několika přístupů?

Neexistuje univerzální odpověď. Velmi podrobný název usnadňuje okamžité pochopení, ale v tabulkách může být obtížně použitelný. Naopak krátký kódovací systém je robustnější a snadněji standardizovatelný, ale vyžaduje referenční příručku nebo konvenci, se kterou jsou uživatelé obeznámeni.

Stejné úvahy platí i pro samotné rodiny: hostovaná nebo nehostovaná rodina, parametry typu nebo instance, úroveň detailu, 2D nebo 3D reprezentace, míra parametrizace a podobně.

Dobrá šablona tedy není jen o poskytování objektů; jde o poskytování objektů, jejichž chování odpovídá očekávaným způsobům práce.

Rozhodování bez pevného stanovení pracovních metod

Další významná výzva spočívá ve způsobu přijímání rozhodnutí.

V mnoha oblastech je technicky možné použít několik řešení. Dobrým příkladem jsou tloušťky čar: Revit nabízí velkou míru svobody, ale tato svoboda může také způsobit, že systém bude obtížně pochopitelný a udržovatelný.

Nejvhodnější řešení proto nemusí být nutně to, které využívá všechny možnosti, jež software nabízí.

Může být vhodnější dát přednost jednoduššímu, snadno zapamatovatelnému a konzistentnějšímu řešení.

Stejná logika platí také pro fáze, šablony pohledů, razítka výkresů, stromové struktury, materiály a konvence pojmenování.

Výzvou není najít nejlepší řešení v absolutním smyslu, ale najít řešení, které nejlépe odpovídá danému kontextu, uživatelům a cílům projektu.

Proto by profesionální šablona měla dokumentovat nejen přijatá rozhodnutí, ale tam, kde je to relevantní, také zvažované alternativy, jejich výhody, omezení a důvody konečného rozhodnutí.

Tato historie návrhu se stává obzvláště cennou, když se šablona vyvíjí nebo přechází do rukou jiných lidí.

Začlenění konceptu postupného modelování

Další důležitá lekce se týká úrovně detailu, kterou je třeba do modelu zavést.

Často je lákavé pokusit se hned od začátku definovat finální technické skladby, konečné materiály nebo kompletní sadu vlastností objektu.

Projekty se však vyvíjejí.

V raných fázích může být obecný prvek pro danou potřebu dokonale vhodný. Umožňuje pracovat s objemy, plochami a celkovou orientací, aniž by byly předčasně stanoveny konstrukční volby.

S postupným rozvojem projektu lze prvky nahrazovat nebo zpřesňovat.

Tato logika se vztahuje také na 2D a 3D reprezentace. Možnost dočasně nebo příležitostně pracovat s 2D prvky může být užitečným mostem pro uživatele přicházející z AutoCADu a zároveň cenným nástrojem pro rychlé provádění určitých studií nebo posouzení proveditelnosti.

BIM proto nemusí nutně znamenat okamžité vymodelování všeho.

Znamená dosažení úrovně definice odpovídající sledovanému cíli.

Fáze ukazují, jak vzájemně propojená jsou tato rozhodnutí

Správa fází je dobrým příkladem toho, jak složitá může šablona ve skutečnosti být.

Volba mezi hostovanou a nehostovanou rodinou může mít významné důsledky, pokud projekt zahrnuje stávající konstrukce, demolici a rekonstrukci.

Podobně volba fází ovlivňuje tvorbu pohledů, grafické filtry a přípravu výstupů.

Některá rozhodnutí je proto nutné přijímat s ohledem na jejich vzájemné souvislosti se zbytkem prostředí.

To je pravděpodobně jedna z klíčových lekcí projektu šablony: žádné téma není nikdy zcela nezávislé na ostatních.

Ilustrace správy hostovaných a nehostovaných rodin:

Na šablonu je třeba nahlížet jako na živé prostředí

Předání souboru .RTE není koncem projektu.

Naopak znamená začátek nové fáze: používání v reálném prostředí.

První projekty odhalí, které potřeby se skutečně opakují, které rodiny chybí, které šablony pohledů se nepoužívají, které úkoly se opakují, které parametry nejsou intuitivní a které konvence fungují hůře, než se očekávalo.

Proto je obzvláště cenné vytvořit pilotní projekt doplněný o strukturovanou zpětnou vazbu.

Vylepšení lze následně prioritizovat a postupně začleňovat zpět do šablony.

Tento přístup proměňuje šablonu v produkt, který se s každým projektem zlepšuje, namísto pevného souboru, který je jednou provždy předán.

Dokumentace je součástí šablony

Komplexní šablona se nemůže spoléhat pouze na intuici svých tvůrců.

Dokumentace umožňuje předávat rozhodnutí, vysvětlovat konkrétní chování a především zachovat důvody, které za nimi stojí.

Pomáhá také rozlišovat mezi několika úrovněmi informací:

• obecné zásady;
• konvence;
• technické možnosti;
• volby provedené klientem;
• podrobné postupy;
• získané zkušenosti;
• oblasti pro budoucí rozvoj.

Tato struktura se stává obzvláště důležitou, když je třeba šablonu převzít, udržovat nebo dále rozvíjet jinými lidmi.

Dokumentace se pak stává skutečnou pamětí projektu.

Směrem k opakovatelné metodě návrhu

Zkušenosti nakonec ukazují, že šablona Revit by neměla být navrhována jako soubor nastavení, ale spíše jako koherentní systém rozhodnutí.

Každé téma – rodiny, materiály, grafika, fáze, výkazy, knihovny, parametry, interoperabilita, spolupráce – by mělo být prozkoumáno, porovnáno, zváženo a následně zdokumentováno.

Tento přístup otevírá cestu k opakovatelnější metodě:

Analyzovat → Navrhnout → Porovnat → Rozhodnout → Vyvinout → Otestovat → Zdokumentovat → Rozvíjet.

Standardní příručka se pak stává referenčním bodem pro možnosti a získané zkušenosti. Klientská příručka je její přizpůsobenou verzí, obohacenou o skutečně provedené volby a důvody, které za nimi stojí. Technické listy pak umožňují podrobněji rozpracovat konkrétní témata, která vyžadují hlubší zpracování.

Závěr

Úspěch BIM šablony se v konečném důsledku neměří počtem rodin, které obsahuje, počtem parametrů, které zpřístupňuje, ani počtem pohledů, které předem konfiguruje.

Měří se její schopností umožnit týmům pracovat konzistentním, srozumitelným a efektivním způsobem a zároveň zůstat dostatečně flexibilní, aby se mohla vyvíjet.

Dobrá šablona se nesnaží předvídat každý projekt.

Jejím cílem je poskytnout pevný rámec pro projekty, které ještě neznáme.

Právě v tom pravděpodobně spočívá její hlavní výzva: vytvořit dostatek standardů, které zajistí společný základ, aniž by se tyto standardy změnily v omezení, která by projektu bránila přizpůsobovat se.

A toto uvažování nekončí po dodání první šablony. Naopak otevírá nepřetržitý cyklus experimentování, zpětné vazby a zlepšování, v němž se šablona, dokumentace, pracovní metody i uživatelé vyvíjejí společně.