OpenPath
OpenScape => OpenScape - Business => Topic started by: Kimera on December 18, 2013, 08:51:11 am
-
Salve,
qualcuno si è fatto una opinione "ponderata" (in termini di Marketing, in termini Tecnici ed Economici) su alcuni scenari di migrazione in oggetto?
Saluti, Kimera.
-
Alcuni pareri posso darli:
1) Nella migrazione delle licenze dei primari le 2 licenze di base si perdono (e sarebbe stato bello saperlo)
2) Sempre le licenze di primario sono abbinabili all' interfaccia solo in quantità pari, il che vuol dire che un cliente con 15 canali pri o ne usa uno in meno o ne paga uno in più.
Per questi problemi ho già aperto segnalazioni e sto attendendo risposta.
ciao
-
Ciao Lucky,
aggiungo che (da quel che mi è parso di capire in un recente Workshop su OSB V1) il passaggio da HiPath 3000 V9 (sia che questo abbia una implementazione IP che una semplice Full-TDM) sia tutt'altro che indolore sia in termini tecnici che in termini economici (di conseguenza la strategia di marketing adottata da Unify/Siemens si sta rivelando per lo meno sindacabile sotto molti punti di vista).
Penso solo al caso di due macchine HiPath 3000 connesse in IP Trunk via HG1500...il passaggio a OSB V1 (che sia o meno giustificato dal desiderio di avere la Smart UC o la Full UC) è tecnicamente difficile da capire (perdita dell'HG1500 e dell'IP-Trunking / SIP Providers liberi e obbligo di "riconquistarne" parte delle funzionalità comprando nuovo Hardware ad-hoc per OSB e nuove relative Licenze che prima non esistevano neppure) e difficile da far digerire alla clientela finale.
-
Ciao
Il problema dell'assegnazione delle licenze PRI è stato risolto con la Release V1.R2.1_0279.
I due canali sono definitivamente persi, Unify dice che già dalla V9 non c'erano più, a mè non risulta.
Comunque il costo, soprattutto per macchine in rete non è poco.
-
Potremmo anche entrare nel dettaglio (vedi caso dei Canali PRI) ma, prima ancora di farlo, occorre fare una valutazione "generale": non vedo argomentazioni valide per migrare un sistema HiPath 3000 V9 (soprattutto se ha OSO HX) ad OSB V1 benchè tale migrazione diverrà obbligatoria (nel senso che, con il passare del tempo, verranno a mancare materiali/licenze per i sistemi HiPath 3000 V9 e precedenti).
Domanda:
Quali sono i benefici realmente fruibili da un Cliente (a patto che un tale Cliente rappresenti il "Cliente medio" che già possiede un sistema HiPath) che intende avvalersi (o anche solo provare) delle funzionalità UC (Smart/Full) proposte da Siemens se quest'ultimo (a) non ritiene nemmeno necessarie tali funzionalità oppure (b) le sta già utilizzando nella misura e nel modo con i quali sono già fornite nella loro versione attuale (vedi caso di Clienti che hanno sistemi HiPath 3000 V9 + OSO HX V3 oppure il caso di Clienti con sistemi OSO MX/LX)?
Mi sembra che il passaggio da HiPath 3000 V9 (e non parliamo di sistemi più datati!) a OSB V1 comporti una sorta di impoverimento (paradossale!?) Hardware (benchè nuove funzionalità siano state integrate nella nuova comune Motherboard per ritornare ad avere quello che si aveva prima bisogna dotare la macchina di sub-moduli per l'espansione dei canali DSP...ad esempio) ed una lievitazione dei costi in termini di "Features Licensing" (ovvero devo licenziare cose che prima non necessitavano di alcuna licenza per funzionare).
-
A me addirittura mi hanno detto che i 2 canali "omaggio" erano solo per 3800. Vabbeh, no comment, ma ovviamente confermo che nella V9 le 2 licenze di base persistevano nella loro esistenza. Io comunque sto ancora attendendo la risposta ufficiale (non ho ricevuto nemmeno quella ufficiosa)
Per quanto riguarda le migrazioni, non ho avuto particolari problemi se non le questioni sui primari, una volta imparate alcune accortezze/procedure tutto va abbastanza liscio. In effetti la parte networking non l' ho ancora affrontata.
Una parte positiva su OsBiz è l' evm con 6 porte, che permette di evitare una dispendiosa ivm o buster card in molti scenari.
Diciamo che siamo ancora all' alba ma non la vedo più così nera, al massimo un po grigia topo.
-
La migrazione da un HiPath 3000 V9 full-TDM (quindi, supponendolo, senza HG1500 e quindi senza alcuna traccia di funzionalità UC) può essere anche abbastanza indolore - forse tecnicamente - meno economicamente (se infati il sistema di partenza è già equipaggiato con Xpressions Compact cosa me ne faccio delle 6 porte EVM sulla nuova Motheboard dell'OSB V1? ...ogni scenario lascia il tempo che trova quando il sistema di partenza - parliamo di migrazione non di nuovo impianto - ha già una sua "dotazione" significativa). Vi sono sicuramente alcuni casi che prestano il fianco a critiche e temo che siano proprio quelli in cui un sistema ha già, in un modo o nell'altro, implementato servizi IP (o legati all'IP).
-
Salve a tutti,
in fase di migrazione un altro aspetto che può dare delle spiacevoli sorprese, è, che dalla ultima versione appena rilasciata i cordless non professional con sistema dect non danno il clip (schermo completamente nero) e non è un malfunzionamento ma una scelta decisa da Unify.
-
Ciao, sono nuovo del forum, saluto tutti.
Confermo quanto detto sui dect per quanto riguarda la versione dei dect professional, su hipath fino alla v9 almeno sui dect non.professional visualizzava almeno l'interno, una volta passati alla migrazione openscape business X non viene visualizzato nemmeno l'interno.
Altra cosa, nessuno ha ancora provato a collegare un Blues professional per documentaziuone addebiti?
io ci sto provando ma nella parte di recorder non riesco a visualizzare nemmeno una stringa....anche se il centralino è configurato con la parte di documentazione addebiti attiva con IP e porta di ascolto esempio 9000....
Fino alla versione MX v3 il blues funzionava....con openscape business X non va....per ora...
nessuno ha per ora fatto funzionare un blues su opnscape business X?
Grazie
-
Io ho installato appena oggi un Blue's enterprise su un OSBiz X8 ma funziona alla perfezione.
-
Indagando un po mi sembra di aver capito che già in passato qualcuno ha previsto la questione 2 canali s2m perse perchè non presenti nel cls. Per ovviare in una sales information spiegano che nella migrazione da v7 a v9 vengono fornite (regalate) 6 licenze canali s2m e 8 licenze canali b per hg. Il problema si presenta però ne passaggio da una vecchia versione (es v4) dove le licenze di primario non esistevano e la scheda va sostituita perchè non più compatibile. Quindi per arrivare a osbiz si comprerebbe upgrade da v4 a v9 (quindi cambio motherboard), la scheda diut e 13 licenze s2m + migrazione da v9 a osbiz. Ne ho pensate di ogni ma non ho trovato la scappatoia, quindi alla fine l' unica cosa per macchine già v9 o upgrade da <V5 é comprare (magari già osbiz) le 2 licenze mancanti.
Con questo spero di avvisare chi ancora non é incappato nella "trappola"
-
Salve a tutti,
sono nel bel mezzo di una migrazione da 3800 v9 a OSBiz x8 con booster card. 106 utenti tdm e 40 ch b Primario.
Mi sono bloccato sull'esportazione del file xml che serve per migrare le licenze da v9 a Osbiz.
Dopo aver fatto l'inizializzazione di base (OsBIz) spedisco in macchina il database convertito (manager E V.10 R2.3), dopo che X8 effettua il restart la configurazione è ripristinata correttamente (a parte LCR che è vuoto). Ma su registrazione export genero il fle xml e purtroppo contiene solo i miei dati non i dati relativi a mac,utenti e linee utilizzate dal vecchio 3000 V9 che servono per generare il nuovo file Lic su CLS.
Quindi rimetto la vecchia CPU V9 e riparto come prima.
Ora dovrò utilizzare il Card Manager per rifare la scheda SD per poi riprovarci, ovviamente è su un impianto funzionante.
Qualcuno ha qualche idea, mi sono perso in qualche passaggio?
Grazie.
-
Salve a tutti,
sono nel bel mezzo di una migrazione da 3800 v9 a OSBiz x8 con booster card. 106 utenti tdm e 40 ch b Primario.
Mi sono bloccato sull'esportazione del file xml che serve per migrare le licenze da v9 a Osbiz.
Dopo aver fatto l'inizializzazione di base (OsBIz) spedisco in macchina il database convertito (manager E V.10 R2.3), dopo che X8 effettua il restart la configurazione è ripristinata correttamente (a parte LCR che è vuoto). Ma su registrazione export genero il fle xml e purtroppo contiene solo i miei dati non i dati relativi a mac,utenti e linee utilizzate dal vecchio 3000 V9 che servono per generare il nuovo file Lic su CLS.
Quindi rimetto la vecchia CPU V9 e riparto come prima.
Ora dovrò utilizzare il Card Manager per rifare la scheda SD per poi riprovarci, ovviamente è su un impianto funzionante.
Qualcuno ha qualche idea, mi sono perso in qualche passaggio?
Grazie.
Abbiamo avuto lo stesso "problema" con una migrazione da un 3550 V.9 a un OSBiz. Il file generato non contiene nulla, se non i dati del cliente e una "stringa" alfanumerica, non vorrei che avessero modificato il file, facendo in modo che le linee, gli utenti TDM, le licenze ed altro ora non siano più, a vista, ma crittografati in qualche modo. In effetti anche noi ci siamo un po' rimasti, perchè il meccanismo di passaggio precedente mostrava nel file XML tutto quello che effettivamente c'era nel sistema. :-\
Noi abbiamo dato la colpa al fatto che il cliente avesse collegati dei telefoni optiset, e quindi dovremo rifare la procedura a breve scollegandoli e sostituendoli con degli optipoint, ma è chiaramente solo una supposizione. :-\
-
Si anche io ho avuto il dubbio che sia così, mi sembra strano che nel file xml non ci sia data creazione mac del vecchio v9 e del nuovo.....
Cmq ho rifatto la SD ora alle 1300 provo nuovamente i passaggi per vedere che succede.
I miei sono tutti e 72 optipoint poi ho 24 bca e 40 canali per flussi. nel database da convertire in OSBiz su sistema vedo comunque la quantità totale giusta.
Da indicazioni del fornitore sul file xml ci deve essere per forza il mac e i dati relativi a quantità TDM e Trunk, per poter attivare le nuove licenze.
Fra un pò eseguirò nuovamente la procedura per vedere che fà.... :-\
Grazie
-
.... nell'attesa pensavo che se gestivano loro la generazione del file xml partendo dal database attivo del cliente, dove comunque ci sono tutte le info che servono per migrare le licenze. hw schede mac licenze e tdm attivi..
Oggi sono da un cliente che non posso fermare e quindi devo andare a tentativi ovviamente nei momenti possibili.... mha! >:(
-
.... e quindi ho sbaglio qualche passaggio oppure....
i file xml generati non contengono info sull'hardware. Ho confrontato quello di ieri con quello esportato oggi sono identici (signature uguale).
Mha!
<?xml version="1.0" encoding="windows-1252"?>
<inventory_for_license_upgrade>
<ignore_signature>
<user_info>
<publisher_x_ref_number></publisher_x_ref_number>
<company_name>Localnet Livorno </company_name>
<country>Italia</country>
<street1>via umbria 7</street1>
<street2></street2>
<street3></street3>
<city>Livorno</city>
<zip_code>57014</zip_code>
<country_code>IT</country_code>
<company_email>vincenzo.becciu@localnettoscana.it</company_email>
<notification_language>it</notification_language>
<system_type>8</system_type>
</user_info>
</ignore_signature>
<signature>4a09a1ad834a4221cf979db....................................
-
Stesso "problema" che abbiamo riscontrato noi. Metto problema tra virgolette, perchè in realtà io non so se quella è un anomalia o la normalità. So solo che i primi due upgrade che abbiamo fatto i file xml erano diversi ed indicavano chiaramente quanti utenti TDM c'erano e quante licenze c'erano. :-\
-
Ciao
Il problema è la SD card, oppure la versione, prova a rifare la SD con la nuova aps " image_osbiz_v1_R2.2.0_324"
Il file .xml deve contenere il numero di licenze TDM relative al numero di interni funzionante sulla V9.
-
Ciao
Il problema è la SD card, oppure la versione, prova a rifare la SD con la nuova aps " image_osbiz_v1_R2.2.0_324"
Il file .xml deve contenere il numero di licenze TDM relative al numero di interni funzionante sulla V9.
Ciao,
la SD card non è perchè l'ho rifatta ( con procedura utilizzando dvd e lettore sd card esterno) ma dopo il restore su OSBiz il file xml rigenerato nuovamente conteneva le medesime info senza mac ne TDM user vecchia H3K. Ho dovuto rispedire la cpu al fornitore che l'ha generato al volo... facendo i soliti passaggi che facevo io. Quindi alla fine non ho capito dovè il problema, probabilmente sul mio pc con Manager E ( anche se è ultima versione rilasciata).
Comunque gli aggiornamenti sull'istallazione appena terminata settimana scorsa sono:
Il restore del vecchio impianto H3K V9 su OSBIz, ha creato non pochi problemi (tenendo conto che era un impianto attivo e quindi lavorato fuori orario di lavoro) durante la configurazione lcr non completo e interconnessione sip1 non funzionante. Dopo varie prove la saggia decisione di eseguire un ripristino di fabbrica e riconfigurazione a mano del cliente. 72 Optipoint 500 , 24 bca e 40 linee flusso.
Quindi cigliegina sulla torta nell'esportazione del file xml ( fatto dal fornitore ) non mi sono accorto che i tdm user esportati per la licenza erano 77 e non 96. Ormai avevo generato il file di licenza, quindo ho dovuto acquistare i 19 tdm mancanti.
Questo perchè il DB H3K V9 aveva hardware collegato per 96 tdm( pallino verde ) ma per 19 telefoni non avevo inserito il numero d'interno. Ho provato a mandare una mail a CLS riconoscendo il nostro errore nel non aver assegnato il numero... ma la risposta è stata picche.
Quindi upgrade da V9 a OSBiz oltre ad hardware collegato assegnate anche il numero interno.
Mha....
Rimpiango un po le service di Carnelli e Dominjanni!
-
???
Invece io devo dire che non ho avuto grossi problemi, anzi è stranamente andato tutto liscio fino alla fine (fin troppo perchè sono arrivato a caricare la licenza invece di lasciare la macchina nel periodo di prova, quindi non sono riuscito a fargli provare i servizi.
Nel mio caso l'unica criticità presente era che non sapevo come gestire l'IVM, non ci ho messo molto a capire che l'IVM anche sull'OSBiz è un "qualcosa" di "a sè stante" il sistema non genera licenze per le caselle VM, semplicemente lo lascia lavorare eliminando l'EVM ( mi sono chiesto a questo punto se avessi dovuto aprire le caselle sull'EVM per averne le licenze...bho ::) ) la conversione del DB non ha avuto alcun problema, anche se non era qualcosa di particolarmente elaborato, quindi potevo aspettarmelo.
Ho notato che gli handset che sulla versione 9 erano visti come Comfort (pur non essendo dei Professional) vengono visti come comfort anche sull'OSBiz, ovviamente se il cordless viene "ri-registrato" perde la funzionalità e passa in GAP.
A questo proposito io "stickerei" le cose da controllare assolutamente e che sul documento di migrazione non sono presenti, ad esempio quella di mettere numero e nome all'interno TDM (non è scritto da nessuna parte, io lo sapevo, però per brutte esperienze precedenti).
Un'altra cosa che ho notato è che facendo il copia incolla del file xml sul campo della migrazione licenze sul CLS è che il file crea una piccola "riga iniziale" che non va copiata nella fattispecie questa:
<?xml version="1.0" encoding="windows-1252" ?>
perchè generando la chiave di migrazione si viene a verificare un errore e prima di capire che il problema era quello ci abbiamo messo qualche minuto.
Saluti
-
>:(
... ma Hunter ti dirò io ho penato un pò per il restore del db H3k V9, probabilmente per la presenza della booster card, ma inizialmente perche non generava il file .xml. e comunque ho ancora da capire se è un problema sull'istallazione Manager E sul mio portatile oppure bo.
Poca esperienza è la prima che mi capita di migrare, non mancherà occasione.
Comunque riguardo al restore del vecchio db... nella prima installazione, dove di esegue funzione per attivare i famosi 30 canali insterconnessione sip, non mi partiva la procedura ( cosa che ha poi fatto partendo da una situazione di restore complteto) quindi non mi funzionava l'autoattendant, LCR non aveva nemmeno una rotta configurata. Comunque personalmente la prossima la faro partendo da una situazione pulita, non certo da un restore...
Con il file .xml non ho avuto problemi, l'ho copiato tutto editandolo tutto con un file di testo e incollato su CLS.
Riguardo le licenze TDM, penso non si siano comportati tanto bene, nel senso che il database che ho allegato alla mail spedita a CLS per spiegargli che non avevamo messo il numero sulle porte ( dove fisicamente c'erano attaccati i telefoni ) perchè nel bel mezzo di un' ampliamento presso il cliente,
hanno risposto semplicecemente....Dear Mr. Becciu, please purchase the 19 licenses TDM to the customer.
quindi visti i tempi che corrono ( e quello che costano ) al cliente proveremo a fatturare queste nuove licenze NON PREVISTE... spenrando bene...
Non è proprio una bella considerazione dei Partner...
-
C'è di che rimanere sconcertati...evidentemente, viste le esperienze tecniche di migrazione tutt'altro che "lineari" da voi riportate, c'è di che riflettere prima (e, aggiungo pure, al solo pensiero) di passare ad OpenScape Business V1 un sistema che si trova stabilmente in HiPath 3000 V9...personalmente rimango dell'idea che il Vendor abbia complicato molto le cose e mi chiedo: tutto questo a chi giova alla fine (a migrazione conclusa/vendita delle licenze conclusa)? al Vendor? al Partner (che diviene/oppure è già un Partner "sistemistico")? ad entrambi? al Cliente?
P.S. Sarò "polemico" ma un ragionamento si deve fare:
Non capisco (soprattutto di questi tempi) il ragionamento riguardo la mancata generazione delle licenze TDM pro-porta quando ad esse non è assegnato un numero di interno anche se il terminale Up0/E è fisicamente connesso (cosa lecita): se è difficoltoso procedere durante un ampliamento come viene riportato (so che durante un ampliamento ci sono decine di cose da fare/verificare/completare)...questo non significa forse che il Vendor (lo ammetto, mi sto infastidendo a chiamarlo Unify! di unificazione non vedo nulla) ha strutturato il sistema di migrazione per indurre i Partner a comprare (e a rivendere, se ce la fanno...) delle licenze (che prima non esistevano ed il Cliente non era obbligato ad acquistare!) per il solo fatto che viene reso difficile/impossibile conquistarle (in modo più o meno "furbo") durante l'attività di migrazione stessa? o forse in Germania migrano in un altro modo (altra scaletta di update)? mah...
-
hanno risposto semplicecemente....Dear Mr. Becciu, please purchase the 19 licenses TDM to the customer.
quindi visti i tempi che corrono ( e quello che costano ) al cliente proveremo a fatturare queste nuove licenze NON PREVISTE... spenrando bene...
Non è proprio una bella considerazione dei Partner...
:o
Ma che razza di risposta è!? :o
Onestamente avrei risposto con una serie di improperi di vario genere.
Devo dire che il sistema di migrazione delle licenze comunque è di una stupidità disarmante. Semplicemente avrebbero dovuto "conteggiare" gli utenti TDM in base all'equipaggiamento di macchina e non al database perchè chiaramente essendo noi "umani" possiamo commettere errori, errori che tra l'altro non sono evidenziati, perchè sul manuale di migrazione non è scritto da nessuna parte di inserire gli utenti con nome e numero di interno, nè di scollegare eventuali optiset e sostituirli con openstage o optipoint, non è spiegato come vengono "licenziati" i VM, non è evidenziato che i dect passano da confort a GAP e queste per ora sono le cose più evidenti che abbiamo verificato. Ma immagino che che ne saranno altre. ???
Credevo he la parola "partner" significasse che remiamo tutti dalla stessa parte, ma mi rendo conto che non è per niente così.
C'è di che rimanere sconcertati...evidentemente, viste le esperienze tecniche di migrazione tutt'altro che "lineari" da voi riportate, c'è di che riflettere prima (e, aggiungo pure, al solo pensiero) di passare ad OpenScape Business V1 un sistema che si trova stabilmente in HiPath 3000 V9...personalmente rimango dell'idea che il Vendor abbia complicato molto le cose e mi chiedo: tutto questo a chi giova alla fine (a migrazione conclusa/vendita delle licenze conclusa)? al Vendor? al Partner (che diviene/oppure è già un Partner "sistemistico")? ad entrambi? al Cliente?
Onestamente l'unico vantaggio che ho riscontrato nel fare l'upgrade è che l'OSBiz ha una sorta di HG1500 integrato, che le BS4 hanno 4 canali e non vanno licenziate, e che espandere il sistema ha un costo relativamente più basso, perchè se avevo necessità di 15 interni dovevo forzatamente acquistare una scheda da 8 Up0e o 4 BCA, mentre ora il costo della scheda è più basso ma devo pagare le licenze. Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. ???
-
Credevo he la parola "partner" significasse che remiamo tutti dalla stessa parte, ma mi rendo conto che non è per niente così.
Essere Partner...basicamente dovrebbe significare essere "compagni" di viaggio/lavoro/intenzioni...e sì, remare dalla stessa parte adottando un modello di Business che non scontenti nessuno o che accontenti tutti i principali attori coinvolti (Vendor, Partner, Cliente) in egual misura...invece Io vedo ultimamente un netto sbilanciamento. Convincetemi del contrario!
Onestamente l'unico vantaggio che ho riscontrato nel fare l'upgrade è che l'OSBiz ha una sorta di HG1500 integrato
Mi pare però che le potenzialità del media gateway integrato nella Motherboard dell'OpenScape Business non siano proprio comparabili con (nè superiori a)quelle del caro e vecchio modulo HG1500, lo dico anche in termini di termini di funzionalità "libere" dal nuovo modello di Licensing che il Vendor ha adottato (pensa solo al Trunking tra sistemi o verso SIP TS Providers) senza parlare poi dei canali puri gestibili (senza usare moduli aggiuntivi). Spero di non sbagliarmi perchè c'è da perdersi tra i numeri e, soprattutto, nessuno si è preso la briga di effettuare un confronto tecnico che faccia emergere perchè NON passare ad OpenScape Business e rimanere in HiPath 3000 V9 (a parte la ovvia considerazione del EoL che presto o tardi scenderà sulla testa di questi sistemi).
le BS4 hanno 4 canali e non vanno licenziate
Questo però va contestualizzato...quella che indichi è tipicamente una funzionalità che viene usata in sistemi nei quali il sistema DECT è altamente utilizzato e nei quali la copertura radio deve servire un ambiente molto denso di terminali (quindi, in ambienti del genere, se necessiti di questa particolare funzionalità è evidente che sei in un caso in cui ti aumenta anche il costo pro utente cosa che prima, se non mi sbaglio, non accadeva con il vecchio modello di Licensing pur dovendo licenziare i canali aggiuntivi sulle BS).
espandere il sistema ha un costo relativamente più basso, perchè se avevo necessità di 15 interni dovevo forzatamente acquistare una scheda da 8 Up0e o 4 BCA, mentre ora il costo della scheda è più basso ma devo pagare le licenze.
Anche questo dipende da che livello usi per valutare la convenienza della migrazione: una scheda con 8 Up0/E aveva e può continuare ad avere un costo "fisico" anche moderatamente alto, ora invece hanno abbassato tale costo introducendo però la variabile del "Licensing per User" quindi, tu dici, nonostante questo nuovo costo addizionale il costo totale è inferiore...sì ma non tieni conto che per arrivare nella situazione in cui sei in OpenScape Business V1 e puoi goderti questo costo inferiore sugli ampliamenti (MAC) devi aver speso per passare da HiPath 3000 V9 a OpenScape Business V1 e quindi il paragone va fatto a posteriori e non a priori...tenendo dunque in conto anche del costo di migrazione. Allora, a posteriori, il costo pro-porta è effettivamente più basso? lo è sempre? o solo per certe particolari migrazioni/configurazioni o solo per certi nuovi sistemi?
Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. ???
Da quel che leggo, direi di no...soprattutto perchè non sento nessuno (in genere chi NON si lamenta di qualche cosa NON va a scriverlo nei Forum) che invece difende la migrazione non tanto dal punto di vista delle perdite/guadagni tecnici/economici ma dal punto di vista di cosa si perde o si guadagna a passare ad OpenScape Business V1 in termini di servizi...considerando però la situazione media delle PMI in Italia e del loro uso dei servizi UC. E' questo che spaventa.
-
Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. ???
[/quote]
Ha volte è necessario... in questo caso il mio cliente aveva 3800 con 3 schede 24 smlo2 e 1 slmae utilizzava 4 operatori automatici analogici a 4 canali, usati su vari servizi in entrata ( agenzia di viaggi ) con 2 flussi primari 3. Così non si poteva gestire più di 4 chiamate in entrata con il messaggio quindi, invece di inventarsi altre soluzioni con IVM integrati o esterni, abbiamo deciso di upgradare la macchina.
Alla fine, dopo le varie disavventure ( evitabili forse con procedura diversa ) il cliente è soddisfatto del risultato perlomeno era quello che si aspettava. Messaggio in entrata per tutti i clienti messaggio in lingua per chiamate dall'estero ecc.
Penso che una buona soluzione, per la Migrazione da V9 a OSBiz, sia quella di utilizzare il database esistente del cliente e generare la chiave di licenza da parte di CLS direttamente evitando inutili errori e perdite di tempo, presso clienti dove oltretutto l'upgrade e su macchine che sono in produzione!
Ovvio che per noi non è stato indolore in termini economici.
Quindi clienti con impianti "vecchi e perfettamente funzionanti" da poter proporre una soluzione nuova ci sono. Ma..... è dura con i tempi che corrono convincerli, a meno che non parta da una loro necessità!
Saluti a tutti.
-
Curiosità Off Topic: avevate preso in considerazione (ad esempio) l'opportunità di affiancare all'HiPath 3800 V9 (rimodulando la configurazione relativa alle VMs e/o agli Auto-Attendands ed relativi moduli fisici coinvolti) una piattaforma quale l'OSO LX oppure l'OSO HX?
Quali servizi la migrazione da HiPath 3800 V9 ad OpenScape Business V1 ha portato con sè che, nel vostro caso specifico (mi pare con delle problematiche legate soprattutto alla parte VMs/Auto-Attendands per la gestione vocale delle chiamate entranti), non potevano essere gestiti/attivati lasciando l'HiPath 3800 V9 sostanzialmente così com'era (sicuramente con delle riconfigurazioni di programmazione) e dirottando i nuovi servizi UC verso OSO HX od OSO LX?
Saluti, Kimera.
-
Curiosità Off Topic: avevate preso in considerazione (ad esempio) l'opportunità di affiancare all'HiPath 3800 V9 (rimodulando la configurazione relativa alle VMs e/o agli Auto-Attendands ed relativi moduli fisici coinvolti) una piattaforma quale l'OSO LX oppure l'OSO HX?
Bè difronte a una situazione del genere io non so se avrei affiancato un 3800 ad un LX-HX. Credo che sarebbe stata una gestione più complessa del sistema. Onestamente ho sempre preferito le soluzioni "all-in-one" nella fattispecie OSO MX piuttosto che HiPath 3000 con server OSO. Vero che in definitiva ottieni gli stessi servizi, anzi, forse qualcosa di più peculiare, ma credo che la gestione di due apparati, che si parlano, è vero, ma che devi controllare e manutenere in ogni situazione, alla lunga creino un doppio indice di criticità, che su un sistema del genere, deve essere preso in considerazione.
-
Credo che sarebbe stata una gestione più complessa del sistema.
Posso anche essere d'accordo su una simile opinione. D'altra parte bisogna anche essere pronti ad ammettere che la migrazione affrontata, vuoi per un motivo vuoi per un altro, non è stata affatto indolore, letto ciò che si è verificato; viene da chiedersi: "Quanto di quello provato si sarebbe verificato con l'integrazione di un OSO LX o di un OSO HX ad un sistema esistente?".
Ovviamente tutto quanto si discute dipende da come si progetta e realizza un sistema od un suo ampliamento.
Ad ogni modo...per controbattere sul tema della facilità di gestione per il sistema "All In One"...basterbbe ricordare solamente che una soluzione di tale tipo oltre che "compatta" è anche (o può divenire) un "Single Point of Failure".
Una soluzione a componenti separati (HiPath 3000 V9 + OSO LX/HX) permetterebbe invece, da un lato, di applicare ancora il concetto del "Dividi Et Impera" mantenendo sì due entità dalla gestione differente (non credo problematica) ma garantirebbe, dall'altro, anche di poterle controllare e gestire in modo separato e, forse, anche in modo abbastanza autonomo.
Come particolare, non vale poco...soprattutto di questi tempi dove i sistemi hanno la tendenza a specializzarsi e divenire così anche molto complessi.
Che succederebbe infatti se l'OpenScape Business V1 (inteso proprio come appliance "All In One") manifestasse qualche problema/anomalia alle funzioni UC (cosa tutt'altro che improbabile vista la complessità raggiunta)? le funzioni "tradizionali", le funzioni "voce" per capirsi, sarebbero salvaguardate rispetto a quelle UC (ed accadrebbe anche il viceversa) oppure un problema (tecnico/di configurazione/dovuto ad un aggiornamento Firmware) o una manutenzione azzardata manderebbe, rispetto ad una soluzione a componenti separati ma interconnessi, tutto il sistema a gambe all'aria?
Tornando però al tema della differenza dei servizi a cui accennavo, che sì può dire?