მოკლე პასუხი
ყოველი მოთხოვნა უნდა დარეგისტრირდეს როგორც ობიექტი ავტორით, პასუხისმგებელი პირით, სტატუსით, ვადით და შესაბამის მოდელთან, ელემენტთან ან დოკუმენტთან კავშირით. განხილვა სასარგებლოა, მაგრამ გადაწყვეტილების ერთადერთი საცავი არ უნდა იყოს.
რას ხედავს გუნდი
მოთხოვნა ჩატშია, გადაწყვეტილება შეხვედრაზე მიიღება, ფაილი წერილში დევს, ვადა კი ცხრილში. ერთი კვირის შემდეგ გუნდი ვეღარ ამტკიცებს, რომელი გადაწყვეტილებაა მოქმედი, ვინ არის პასუხისმგებელი და მოდელის რომელი კონტექსტი განიხილებოდა.
რატომ მეორდება პრობლემა
საკომუნიკაციო არხები რეესტრის როლში გამოიყენება. შეტყობინებებს, დავალებებს, შეთანხმებებს, დოკუმენტებსა და BIM-ობიექტებს არ აქვთ საერთო იდენტობა, სტატუსების მოდელი და პასუხისმგებლობის ჯაჭვი.
გადაწყვეტის მართვადი გზა
- დაარეგისტრირეთ თითოეული მოთხოვნა ერთხელ და მიანიჭეთ მუდმივი იდენტიფიკატორი.
- ავტომატურად შეინახეთ მოდელის, ელემენტის, ხედის ან დოკუმენტის კონტექსტი.
- დანიშნეთ პასუხისმგებელი, სტატუსი და ვადა.
- შეთანხმებები და ცვლილებები განხილვასთან ერთად ერთ ისტორიაში შეინახეთ.
- დიზაინერებს, BIM-კოორდინატორებსა და ხელმძღვანელებს ერთი და იგივე მიმდინარე სტატუსი აჩვენეთ.
მოსალოდნელი შედეგი
გუნდი ხედავს, ვინ რა მოითხოვა, ვინ არის პასუხისმგებელი, რა შეთანხმდა, რა არის ვადაგადაცილებული და მოდელის რომელ კონტექსტს ეხება საკითხი. გადაწყვეტილებები ადამიანების, ჩატებისა და ფაილების ცვლილების შემდეგაც მიკვლევადი რჩება.
დაკავშირებული RS-Systems გადაწყვეტა
Revit.Messenger
Chats, requests, tasks, approvals and BIM context in one Revit workspace.
Revit.Messenger →
Revit CDE
A controlled project environment for BIM communication, documents, decisions, tasks and project intelligence.
Revit CDE →კითხვები და პასუხები
რატომ არ არის ჩვეულებრივი ჯგუფური ჩატი საკმარისი?
ჩატი ქრონოლოგიური ნაკადია, ხოლო პროექტის მართვას სჭირდება ობიექტები სტატუსით, პასუხისმგებლობით, ვადებითა და დოკუმენტაციასთან კავშირებით.
ყოველი შეტყობინება დავალებად უნდა იქცეს?
არა. მართვადი სტატუსი მხოლოდ იმ შეტყობინებებს სჭირდება, რომლებიც მოქმედებას, გადაწყვეტილებას, შეთანხმებას ან ოფიციალურ პასუხს მოითხოვს.