Allplan Forum: Baukonto/ Baukosten 2014

bmatt

04.01.2014 - 13:58

Sehr geehrte Fa. Nemetschek,

Sie erlauben mir die bescheidene Frage, ob sich für die aktuelle Version 2014 Baukonto und Baukosten noch eine Neuerung nachschieben lässt (damit wenigstens etwas Erwähnenswertes unter Neues in... angeführt werden könnte)?

Es ist allgemein schon länger bekannt, dass zum Februar 2014 die SEPA-Migration im Zahlungsverkehr ansteht. Wider erwarten ist dies in der neuen Version noch nicht berücksichtigt. Seit kurzem ist nun offiziell, dass durch den seitens Nemetschek geplanten Wechsel auf das neue Programm Nevaris, zukünftig nicht mehr länger auf BCM gesetzt wird.
Dennoch ist es enttäuschend für die SP- Kunden, dass an den beiden Modulen zur Ausschreibung und Zahlungsverwaltung- die durchaus wesentlich größeres Nutzungspotential haben/ hätten, seit langem die Entwicklung stagniert. Folgendes liegt sicher nicht an der "toten" Programmiersprache:
- Integrationsmöglichkeit der KEV- Formulare aus dem KVH-Bau (für den Bund arbeiten die wohl die Wenigsten)
- Aktuelle Berichte zu Abnahme
- Durchgängige DIN276 Integration von Baukosten zu Baukonto ohne umständliches Kosten-Splitting (ABM- Maßnahme?)
- .... vor längerem hatte ich weitere Anregungen gegeben, aber Anbetracht der Tatsachen, verzichte ich auf weitere Anführungen

Es wäre sehr nett, wenn wenigstens noch die Möglichkeit zur IBAN/ BIC Eingabe nachegereicht werden würde- vielleicht vor Februar 2014, denn es gibt tatsächlich Benutzer, die die Programme in der täglichen Arbeit anwenden.

Falls Nemetschek auf diesem Ohr hören sollte:
Vorab vielen Dank!

Eventuell berücksichtigt man bei NEM auch für den Umstieg, die Möglichkeit bestehende Adress- Daten aus BCM problemlos nach Nevaris überführen zu können. Aufgrund der sehr mangelhaften (Entweder- Oder- Lösung) Anbindung von BCM an Outlook, wird es hoffentlich dem Anwender später nicht zugemutet, Zig bis Hunderte von Datensätzen aus BCM manuell neu anlegen zu müssen.

Ich hoffe, dass der im sterben liegende Patient BCM wenigstens noch kurz vor dem Ableben so aufgepeppelt wird, dass ein halbwegs zumutbarer Umstieg auf das Auer-Produkt erfolgen kann. Das ist hoffentlich nicht zuviel verlangt und wohl im Sinne aller- zumindest der meisten- BCM User.

Bitte halten Sie Ihr Versprechen auf Durchgängigkeit
. Einerseits wollen Sie den Kunden dazu bewegen, die komplette Produktpalette aus Ihrem Haus zu kaufen, andererseits hinkt die flüssige Verknüpfung der Programme untereinander, mangels gleicher Priorisierung in Sachen Entwicklung. Wir haben aufgrund von IBD auf diese Gesamtpalette gesetzt, weil wir als kleines Büro auf kompakte Verknüpfungen der Arbeitsschritte angewiesen sind, um im Vergleich mit Büros mit höherer Man-Power einigermaßen bestehen zu können. Daher die Bitte, bei der Entwicklung einer Produktfamilie künftig darauf zu achten, dass dem Kunden ein Nutzen daraus entsteht, anstatt durch unnötige Zwischenschritte innerhalb der Produkte oder sogar durch teilw. Auslagerung auf Fremdsoftware zusätzlich Arbeit zu schaffen. Eine halbherzige Geschichte wie zwischen Baukosten und Baukonto sollte es für diesen Preis künftig nicht geben.

Freundliche Grüße,
Bernd Mattern

11 - 20 (31)

CTZ

07.01.2014 - 10:44

Lamentieren wollte ich nicht, nur den Blick auf die Vorgehensweise etwas erhellen. Als ich 2008 auf Grund der Microsoft Meldung bei meiner Hotline nachfragte, was wohl anstelle von Allrigth (auf Basis FoxPro) kommen würde, erhilt ich zuerst die Antwort, daß man davon noch Nichts gehört habe, und später nach erneuter Nachfrage, daß ich sicher sein könne, daß schon dafür gesorgt werde, daß der Umstieg mit gleichem Leistungsumfang glatt und fast unmerklich über die Bühne ginge. --> Es wurde dann der Name Allrigth auf BCM geändert.
Daher der Satz "... jetzt ...".

Übrigens: IBD und California funktionieren sehr wohl miteinander.
Wir hatten vor Allrigth California im Einsatz, und es hat Alles was ein Ausschreiber braucht.
Damals war der Grund für den Umstieg auf Allrigth, die Offenheit der Schnittstellen von Allrigth (BCM).
Dies war bei California nicht bzw. nur scheinbar vorhanden, aber derart behindert, daß es keinen Sinn macht. Die Absicht der Abschottung war deutlich spürbar.
Beispiel: Import / Export nach Excel: Das Ergebnis ist derart formatiert, daß eine Weiterbearbeitung sinnlos ist. Etc.
Wir machen uns jedenfalls auf die Suche nach einer anderen Lösung.
Und: Ja, ich habe Nevaris getestet. Nach 30 Jahren AVA per EDV möchte ich auf Kinderkrankheiten verzichten.
Außerdem lehne ich ein bearbeiten von Projekten "in der Cloud" strikt ab.
Wir haben Auftraggeber, die uns rauswerfen würden, wenn wir auch nur Teile ihrer Projekte veröffentlichen würden. Dafür muß ich regelmäßig unterschreiben.

07.01.2014 - 13:28 *

Die Datenhaltung in der Cloud ist bei Nevaris nur eine der Möglichkeiten, im Lizenzmodell können die Daten auch auf einer lokalen Festplatte oder einem FileShare liegen oder es kann ein Microsoft SQL-Server für die Datenhaltung genutzt werden.

Abgesehen davon würde ich bei der Datenhaltung in der Cloud nicht von "Veröffentlichen" der Daten sprechen. Ich bin mir sicher, viele private Netzwerke sind schlechter abgesichert.

bmatt

07.01.2014 - 13:35

Mit IBD geht nicht, meinte ich die Projektrecherche. Die IBD- Bauelemente lassen sich ja vermutlich nicht in California einlesen, ohne sie als GAEB aus BCM zu exportieren.
BCM ist ja quasi schon nicht mehr da. Was mache ich dann mit IBD? IBD macht für uns Sinn als Komplettlösung Design-2-Cost. Nur wegen der netten Assistenten/ IBD-Planungsdaten brauchen wir das nicht zwingend. Die waren als Appetizer ganz gut, bzw. haben funktioniert, dass wir "mit alles bitte" nun haben. Ich prüfe die nächste Zeit wie "IBD-abhängig" wir tatsächlich sind.

07.01.2014 - 13:39 *

Die GAEB bietet kein Datenformat für den Transport von Bauelementen.

Für Nevaris existiert bereits (aktuell intern) eine Möglichkeit, aus BCM Bauelementkataloge zu übernehmen.

CTZ

07.01.2014 - 13:55

... können die Daten auch auf einer lokalen Festplatte oder einem FileShare liegen oder es kann ein Microsoft SQL-Server für die Datenhaltung genutzt werden. ...

Programm läuft also in der Cloud, also werden die Daten auch in der Cloud bearbeitet, und sind damit "abgreifbar".
Wo steckt der tiefere Sinn, und der Nutzen für den KUNDEN? Wir spielen hier nicht.
Und ein gemeinsames arbeiten war bisher auch ohne Cloud möglich.
Daten unterwegs von UNSEREM Server laden kann ich schon seit Jahren.

Die kategorische Ablehnung einer angreifbaren Datenbearbeitung kommt nicht aus einer Laune heraus, sondern wie oben bereits erwähnt - aus Verträgen.

Wenn natürlich die gewünschte Zielkundschaft nur aus Häuslebauern besteht, ist es ja wurscht.

CTZ

07.01.2014 - 13:59

... IBD- Bauelemente lassen sich ja vermutlich nicht in California ...

Diese Vermutung ist wahrscheinlich nicht richtig. Ich erinnere mich an ein Gespräch - da kam die Aussage "es geht".

07.01.2014 - 14:00 *

Quotato da: CTZ

Programm läuft also in der Cloud, also werden die Daten auch in der Cloud bearbeitet, und sind damit "abgreifbar".

Natürlich läuft dann auch die Software lokal.
Das würde ja nun wirklich keinen Sinn machen, die Daten zum Bearbeiten von lokal in die Cloud zu laden.

Nevaris ist "cloudfähig", die Cloud ist aber eine Option, kein Zwang.

07.01.2014 - 14:05 *

Nachtrag: Es gibt einen Punkt, der immer in der Cloud läuft, und das ist die Benutzerverwaltung.

bmatt

07.01.2014 - 14:20

Quotato da: CTZ

[quote]... IBD- Bauelemente lassen sich ja vermutlich nicht in California ...

Diese Vermutung ist wahrscheinlich nicht richtig. Ich erinnere mich an ein Gespräch - da kam die Aussage "es geht".
[/quote]

Von wem? Das wäre ja interessant... gerne PM

CTZ

07.01.2014 - 14:54

Frage: WARUM muß die Benutzerverwaltung in der Cloud laufen?

11 - 20 (31)