no, sicuramente non è corretto banalizzarli, e non è nemmeno possibile capirne qualcosa con assoluta certezza. Io stavo ragionando sul fatto che a quanto pare la vendibilità per nuove attivazioni è sempre la prima a sbloccarsi, e nel caso di wholesale, seguirà presumibilmente gli aggiornamenti forniti da TIM. Mentre la migrabilità in myfast page, segue strade e criteri meno trasparenti, e che è ancora più difficile comprendere. Ma davo per scontato che qualsiasi sistema automatizzato, difficilmente avrebbe potuto sbloccare la seconda, quando ancora non ci fossero le condizioni per la prima. Da qui la mia riflessione.
Caso strano di passaggio da ADSL 6 MEGA a presunta FTTC 100 MEGA NGA FASTWEB
fracar77_ Mentre la migrabilità in myfast page, segue strade e criteri meno trasparenti, e che è ancora più difficile comprendere. Ma davo per scontato che qualsiasi sistema automatizzato, difficilmente avrebbe potuto sbloccare la seconda
Di sicuro c'è un sistema automatizzato dietro, ci certo non le sbloccano a mano civico per civico, la potabilità credo dipenda da tantissimi fattori interni, tecnologia utilizzata, tecnologia di migrazione, costi ecc ecc.
E' risaputo che tutte le compagnie (da quelle telefoniche, alle assicurazioni ecc) cercano di portare dentro nuovi utenti, probabilmente burocraticamente ed economicamente preferiscono far andare via un vecchio cliente e farlo riabbonare che cambiare contratto e tecnologia.
skioppa tantissimi fattori interni, tecnologia utilizzata, tecnologia di migrazione, costi ecc ecc.
Infatti. Lato utente sembra molto semplice, ma in realtà dietro il sistema dovrebbe preparare un ordinativo che è del tutto analogo a una migrazione a un altro operatore, con tutte le variabili del caso.
fracar77_ Quale script/procedura automatica può attivare un account se il db della vendibilità non ha vendibilità? A me pare ridicolo.
Qualsiasi sistema informativo aziendale è soggetto alla convivenza di tecnologie e strutture dati legacy e nuove, come sia incasinata questa convivenza dipende da quanto una azienda investe in forza lavoro e tecnologia competenti per rimanere al passo coi tempi.
Comunque le incongruenze e gli errori capitano sempre quando si mettono insieme una miriade di tabelle diverse, se sei uno sviluppatore sai perfettamente che anche se va tutto nell'ambiente di sviluppo, poi quando porti in produzione ci può essere una qualche eccezione che non era saltata fuori prima.
- Modificato
rami Infatti. Lato utente sembra molto semplice, ma in realtà dietro il sistema dovrebbe preparare un ordinativo che è del tutto analogo a una migrazione a un altro operatore, con tutte le variabili del caso.
sì, su questo non ci son dubbi. E aggiungerei anche che oltre alle variabili più tecniche e/o legate ai costi, ci sarà sicuramente anche un comprensibile progredire a scaglioni, per non trovarsi con migliaia di pratiche da gestire tutte assieme. Comprensibilissimo, e su questo, anche se mi piacerebbe, sarà difficile capire mai qualcosa.
Alla fine mi focalizzavo solo sul dettaglio di come potesse essere stata flaggata l'attivabilità su myfastpage, pur non risultando la copertura commerciale. Avrei detto che il controllo sul db della copertura fosse la prima condizione necessaria per poter attivare la migrabilità, a prescindere da ogni altra condizione, e che il db della copertura fosse univoco ma, visti i fatti, c'è sicuramente altro o qualcosa che non ha funzionato a dovere. Diciamo che fra tutti i problemi e incongruenze che si sentono in giro, questa mi è suonata più borderline, più strana.. Tutto qua. 