Hilfe bei Argumentation für Opensource TK-Anlagen

[Kintac]

----------

 

[RealHendrik]

Vorschlag: Trenne Dich von diesem neutral beratendem Ingenieurbüro. Mache Dich selbst schlau - ganz offensichtlich tust Du das schon - und wenn Du zu einem brauchbaren Schluß gekommen bist, dann suche Dir jemanden in Deiner Nähe, der genau Deine Ideen umsetzen kann.

Gruss,

Hendrik

 

[Kintac]

Wenn das nur so einfach wäre. Der Typ wurde mir von oben vorgesetzt und ist leider nicht zu entfernen...

 

[foschi]

Na dann wollen wir mal einen "neutralen Planer" (der warscheinlich eine satte Provision für die Empfehlung des TK-Anlagenherstellers bekommt) etwas ins Handwerk pfuschen.

[...] jegliche Alternativvorschläge mit irgendwelchen Pseudo-Totschlagargumenten und Geschichten aus seiner "langjährigen Erfahrung" niedermacht oder ins Lächerliche zieht.

Bitte sammel/dokumentier solche Aussagen, am besten schriftlich mit Datum und Uhrzeit versehen, ggf. mit Zeugen. Auf diese Aussagen würde ich mich dann beziehen, und diese minutiös auseinandernehmen. Diese Planer haben meistens wenig Ahnung von der Betriebstechnik ansich. Aussagen wie die von Dir beschriebenen kenne ich aus meiner beratenden Tätigkeit von solchen Planern zur Genüge.

Man muss ganz einfach Aussage für Aussage auseinandernehmen und widerlegen - und so den Planer einmal ins richtige Licht rücken.

Entweder heißt es, dass die Funktion X entweder nicht von "allen" Herstellern (A, A, C, S) unterstützt würde, auf die man doch in einer Ausschreibung achten müsste, oder es würden bei Hersteller S horende Lizenzkosten dafür anfallen und man dieses dann nur in einem eingeschränkten Umfang fordern dürfe.

Hm? Warum darf man eine solche Funktion nicht fordern dürfen?

"Chefsekretärfunktion:
- Im SIP-Standard ist diese nicht festgelegt. Dieser dürfe also erst garnicht verwendet werden. In den herstellereigenen Protokollen sind die Funktionen dagegen natürlich vorbildlich gelöst."

Die Funktionalität Chef/Sek ist in SIP natürlich nicht festgelegt, sondern eine Funktion des Vermittlungskerns. Der Vergleich ist so als würde man sagen: Chef/Sek ist im ISDN nicht enthalten, daher darf man ISDN erst gar nicht verwenden. Für ISDN kannst Du auch S0 bzw. Up0, Uk0 o.ä. nehmen.

Chef-Sek-Beziehungen kann man aber prima mit dem Vermittlungskern, der zur Ansteuerung der Endgeräte SIP nutzt, realisieren.

Wie sieht es hier mit Asterisk, SIPxecs, Freeswitch, etc. aus? Können die Funktionen (z.B. auch "Anrufschutz druchbrechen" anders nachgebildet werden?

Warum anders? Man kann doch einfach bei Asterisk, z.B. mit snom-Telefonen, eine Chef-Sek-Beziehung so bauen und auf den Endgeräten konfigurieren wie bei den "klassischen" TK-Systemen auch. Und dann kann man natürlich auch den "Anrufschutz" bzw. die Rufumleitung (die man an dieser Stelle nutzen kann) durchbrechen.

In der Leistungsmerkmal-Vergleichsdiskussion kommt eine OpenSource-System auf Basis von Asterisk schlechter weg - weil es eben von Haus aus weniger kann. Das was es kann reicht aber für 80% aller Einsatzfälle in der Telefonie. Und die 20% fehlende Funktion kann nachgeleistet werden (OpenSource), so jemand darin einen Nutzen sieht.

Der Einsatz einer OpenSource-Lösung liegt in der Hersteller-Unabhängigkeit und Offenheit, und in der Auflösung der vom Planer gewünschten Abhängigkeit vom Geschäftsmodell der "klassischen" Hersteller. Damit kannst Du bei jedem Entscheider ne Menge Punkte holen...

Aber wieder zur Technik. Was gibt es für weitere Aussagen?

 

[woprr]

Wenn das nur so einfach wäre. Der Typ wurde mir von oben vorgesetzt und ist leider nicht zu entfernen...

Dann besteh unbedingt auf Micro$oft Office Communication Server. Mit allem anderen fällt der bei seiner Sachkompetenz garantiert auf die Schnauze:

Die Funktionalität Chef/Sek ist in SIP natürlich nicht festgelegt, sondern eine Funktion des Vermittlungskerns.

Ja. Dem fehlt wesentliche Engineering-Grundlagenbildung wie ISO OSI.

Der Rest ist die alte Open-Source/Proprietär- Make or Buy- Frage ob man lieber Geld für Lizensgebühren und billiges Personal ausgibt und dann 3 Monate auf Firmwareupdates zur Fehlerbehebung wartet oder lieber das Geld für qualifiziertes Personal ausgibt, dass es viel schneller hinbekommt und stabilen Betrieb gewährleistet.

 

[Kintac]

----------

 

[woprr]

Wem stimmt man wohl letztendlich zu? Einen dahergelaufenen Mitarbeiter oder einem im ganzen Bundesland bekannten Ingenieur, der nach eigenen Aussagen und Erlebnisberichten in vielen Behörden und Ministerien für den letztendlichen Kauf der TK-Anlage verantwortlich war?

Alles klar. Fall für den Steuerzahlerbund

 

[RealHendrik]

Wem stimmt man wohl letztendlich zu? Einen dahergelaufenen Mitarbeiter oder einem im ganzen Bundesland bekannten Ingenieur, der nach eigenen Aussagen und Erlebnisberichten in vielen Behörden und Ministerien für den letztendlichen Kauf der TK-Anlage verantwortlich war?

Unabhängig davon, dass er - so wie Du es schilderst - viel Müll erzählt, solltest Du doch mal den "landesweit bekannten Ingenieur" namentlich bekanntgeben. Man sollte sich vor ihm hüten.

(Eigentlich hat er nur einen Fehler gemacht: Er hat sich (nach Deiner Aussage) als "neutral beratend" bezeichnet. Dazu muss er aber ein horrendes Fachwissen haben, das er m.A. nicht hat.)

Gruss,

Hendrik

 

[gandalf94305]

Mal zurück zur ursprünglichen Frage... ;-)

Lassen wir den Inhalt des Ganzen Themas doch mal ziemlich außer acht und betrachten nur den Prozess, der einzuhalten ist, um hier überhaupt ein sinnvolles Ergebnis zu erhalten.

Die fachlich verantwortlichen Personen im Unternehmen sind die Anforderungsgeber. Daher ist auf ihrer Basis zunächst einfach mal ein Anforderungsdokument zu erstellen, das alle Anforderungen enthält, die gestellt werden (sinnvoll und unsinnig). Anforderungen gibt es in diesen Sorten:

- funktionale Anforderungen (bestimmte "Funktionen" eines Systems, z.B. Vermitteln durch Rückfrage/Auflegen, Konferenzen, Wahlregeln, LCR)

- nichtfunktionale Anforderungen (z.B. Mengengerüste, Performanceangaben, Netzwerkbandbreiten, Topologie zur Integration externer Home Offices/Außenstellen)

- Rahmenbedingungen (z.B. Betriebsvorgaben, Vorgaben an Dokumentation und Release Management)

Zu den funktionalen Anforderungen gibt es dann i.a. die Punkte

- "Gegenstand der Anforderung" (z.B. "es muss möglich sein, eine Konferenzschaltung mit max. 15 internen und externen Teilnehmern herzustellen"),

- "Nutzen/Aufwand" (Wann kommt dieser Anwendungsfall vor? Was ist der Nutzen der Funktion? Welchen Aufwand haben Anwender mehr/weniger, wenn diese Funktion bereitgestellt wird? Was ist die Konsequenz, wenn diese Funktion nicht bereitgestellt wird?)

- "Priorisierung" (A = unverzichtbar; B = wichtig, jedoch nicht kritisch; C = schön, aber nur optional; dies ggf. auch im Rahmen eines Rollout-Plans, der zeitlich bestimmte Leistungsstufen fordert)

Jede einzelne Anforderung erhält eine Nummer.

Dann sollte man sich intern Gedanken über die generelle Größenordnung eines möglichen Budgets für dieses Projekt machen.

Ein Ingenieurbüro/Berater kann natürlich an verschiedenen Stellen beitragen und insbesondere auch Empfehlungen abgeben. Eigentümer der Anforderungen ist jedoch der Anwender/Nutzer. Es kann nicht sein, daß eine Anforderung generell fallen gelassen wird, nur weil ein Berater sagt, das wird schwierig. Ok, dann ist es schwierig, aber dann muss man einerseits die Priorisierung der Forderung aus der Fachlichkeit heraus festlegen, und andererseits sehen, wer das erfüllen kann.

Beispiel: wenn Du 1800 Nutzer hast, dann kannst Du anhand der heute vorhandenen Leitungsbündelauslastung mal eine Basisanforderung (Prio A) festlegen. Das sind dann wahrscheinlich so um die 30-90 Kanäle (2-5%), je nach der Art Eures Geschäfts. Habt Ihr erhöhten Bedarf, mehr Kanäle als Peakleistung zur Verfügung zu haben, dann wäre das ebenso zu definieren (z.B. Peak 180 Kanäle), jedoch mit einer Priorisierung. Vielleicht ist diese Peakanforderung dann nur noch B. Die Maximalforderung für 1800 Kanäle wäre Prio C. In Konsequenz wären z.B. auch die Bandbreitenanforderungen der Lösung unterschiedlich. Bei G.729 (ca. 32 kB/s) für einen Kanal wären dies ja schon ca. 56 Mbit/s symmetrisch nur für VoIP, wenn man das für 1800 Kanäle auslegt.

Parallel zum Anforderungsdokument (das dann zu Anbietern gehen kann) und dem internen Budgetplan (der zunächst mal grob festgelegt ist), muss man eine Kriterienstruktur erstellen, die alle Anforderungen mit A/B/C-Bewertungen enthält. Für alle A/B/C-Punkte gibt es entsprechende Bewertungen (z.B. A mit 6..9 Punkten, B mit 3..5 Punkten, C mit 1..2 Punkten).

Ein Berater kann beim Aufstellen der Anforderungen, der Kosten/Nutzen-Betrachtung, der Priorisierung und der Bewertung der Kriterien helfen. Ein Berater kann auch potentielle Anbieter vorschlagen. Die Entscheidung muss jedoch beim Unternehmen liegen.

Nur so läßt sich einigermaßen für alle nachvollziehbar ein Anforderungsprozeß für die Ausschreibung herstellen. Ob das OpenSource, Alcatel/Lucent, Avaya, Cisco, Siemens, T-Systems oder sogar eine virtuelle Anlage im Internet ist, muss man hier überhaupt noch nicht diskutieren oder entscheiden. Das ergibt sich auf Basis der Anforderungen und der Antworten von Anbietern.

Also wäre meine generelle Empfehlung: hole Dir als (vermutlich) Fach- oder IT-Verantwortlicher für das Thema das Mandat von der Geschäftsführung, diesen Anforderungs- und Ausschreibungsprozess ähnlich wie beschrieben durchzuziehen. Daraus entstehen abgestimmte Dokumente, die entsprechend nach Review und Überarbeitung abzunehmen sind. Berater helfen ggf. bei der Erarbeitung mit. Laß Dich nicht auf Diskussionen ein, die bereits bestimmte Lösungen präkludieren oder unmittelbar dadurch favorisieren, daß bestimmte Anforderungen unter den Tisch fallen oder über Gebühren herausgestellt werden.

Für die Frage nach OpenSource/proprietär ist es zu früh. Gibt es fachliche/nichtfunktionale Anforderungen oder Kostenrandbedingungen im resultierenden Angebot, dann ist das ggf. der entscheidende Punkt. Hat ein Unternehmen eine "präferiert OpenSource"-Strategie, dann ist das eine Anforderung, die zu einer bevorzugten Behandlung von OpenSource führt (Bewertungskriterien). Die virtuelle Anlage im Internet bzw. am Ende einer Standleitung mit definierter Bandbreite kann die kostengünstigste Lösung sein, hat jedoch ggf. Probleme mit der Verfügbarkeit und der Integration in interne Systeme (z.B. CRM). Alles ist abzuwägen... wenn die Angebote vorliegen.

Denn: gibt es eine Funktion wie die gewünschte Chef/Sekretariat-Schaltung in allen wesentlichen Herstellerprodukten nicht, nur in einem OpenSource-Produkt, dann ist die Frage nach einer Abwägung zu stellen... vorab in den Bewertungskriterien, nachgelagert sobald die Angebote vorliegen. Können alle diese Funktion nicht bereitstellen, dann hat keiner die Punkte... ist die Funktion unverzichtbar und nur einer kann das, dann ist der Entscheidungsraum kleiner geworden. Stellt man fest, daß die A/B/C-Priorisierung nach Vorliegen der Angebote noch zu modifizieren ist, dann gibt es eine Runde ggf. mit der Geschäftsführung, das zu tun.

--gandalf.