МТС Украина заинтересовалась провайдерами проводного интернета

[nevermore 32]

 

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

[Бонарь Юрий 13]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

[_WesT_ 1 016]

Стесняюсь спросить... какой простой 2-3 дня? Вы что? Да за такой простой клиенты на второй день перебегут к конкурентам.

[mlevel 52]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Підкажіть будь - ласка систему яка може самостійно аналізувати проблеми на комутаційних вузлах, проводити моніторинг, відображати інформацію про виключно всі пов'язані проблеми в профайлі користувача. Відповідно ця система має бути оптимізована для роботи саме ISP і відповідати стандартам ITIL.

[Бонарь Юрий 13]

Извините за мое невежество, но что такое oss/bss?

Система для забезпечення бізнес-процесів в середині підприємства. Грубо кажучи це єдина система, яка обєднує в собі біллінг, helpdesk, бухгалтерію та документооборот.

 

Всего то навсього? А я думав що це щось дуже круте для нашого брата, а така стандартна штука.

Наприклад ми цей комплекс активно допрацьовуємо зараз.

 

Это хорошо что дорабатываете.

 

Но если для Вас это всего навсего что то там то видимо Вы не понимаете всей ценности

[Бонарь Юрий 13]

Стесняюсь спросить... какой простой 2-3 дня? Вы что? Да за такой простой клиенты на второй день перебегут к конкурентам.

 

Да ладно вам, узел комутационный уровня доступа где сидит 10-15 абонентов. Выделывался например линк оптический, и по определенным причинам чинили но не всё и не сразу поднялось.

[Бонарь Юрий 13]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Підкажіть будь - ласка систему яка може самостійно аналізувати проблеми на комутаційних вузлах, проводити моніторинг, відображати інформацію про виключно всі пов'язані проблеми в профайлі користувача. Відповідно ця система має бути оптимізована для роботи саме ISP і відповідати стандартам ITIL.

 

Я работаю с такими решениями. Они являются закрытой разработкой

[nevermore 32]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

1 - не бывает такого, что-бы простой был 2-3 дня. Если проблема с коммутатором - меняется пулькой, абоны номер набрать не успеют.

2 - Естественно. А у Вас по другому?

Чета какие то у Вас проблемы странные

[Бонарь Юрий 13]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

1 - не бывает такого, что-бы простой был 2-3 дня. Если проблема с коммутатором - меняется пулькой, абоны номер набрать не успеют.

2 - Естественно. А у Вас по другому?

Чета какие то у Вас проблемы странные

 

Пулькой? Какой провайдер?

[nevermore 32]

Пулькой? Какой провайдер?

АК-47

пулькой в смысле очень быстро

[mlevel 52]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Підкажіть будь - ласка систему яка може самостійно аналізувати проблеми на комутаційних вузлах, проводити моніторинг, відображати інформацію про виключно всі пов'язані проблеми в профайлі користувача. Відповідно ця система має бути оптимізована для роботи саме ISP і відповідати стандартам ITIL.

 

Я работаю с такими решениями. Они являются закрытой разработкой

Я тоді не розумію суті Вашої критики. Наприклад свої напрацювання по напрямку CRM, ERP, Billing, HelpDesk, Monitoring (Вашими словами - це "костилі") я теж можу назвати закритим внутрішнім проектом(розробкою).

З чого Ви взяли що Ваші рішення - "не костилі"?

Судити про чуже ПО, не бачивши його, це, як би виразився пан NEP, те саме що "рассказывать про шумлеса, если вы никогда не были в лесу".

[Бонарь Юрий 13]

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Отлаженная инфрастурктура? да здесь даже мегаоператоры не могу похвастатся наличием комплексного мониторинга и контроля своей инфраструктуры.

 

 

Мегаоператоры может и не могут похвастаться, но у других (не мега) и CRM, и ERP присутствуют, и мониторинг есть, и саппорт круглосуточный.

 

Кучка софтинок, которые друг с другом взаимодействуют через костыли и т.д.

 

Простой пример, была проблема на комутационном узле, простой 2-3 дня. Операторы в биллинге увидят эту информацию в карточке абонента когда абонент через месяц позвонит и попросит пересчитать или компенсировать простой???

 

Пример номер ту. Тоже простой. Планирование работы по переключению каких либо downlink на узле районного уровня. Будет в системе мониторинга учтено затрагиваемые обьекты и будет ли система считать это плановой работой а не проблемой?

 

Примеров еще много...

Підкажіть будь - ласка систему яка може самостійно аналізувати проблеми на комутаційних вузлах, проводити моніторинг, відображати інформацію про виключно всі пов'язані проблеми в профайлі користувача. Відповідно ця система має бути оптимізована для роботи саме ISP і відповідати стандартам ITIL.

 

Я работаю с такими решениями. Они являются закрытой разработкой

Я тоді не розумію суті Вашої критики. Наприклад свої напрацювання по напрямку CRM, ERP, Billing, HelpDesk, Monitoring (Вашими словами - це "костилі") я теж можу назвати закритим внутрішнім проектом(розробкою).

З чого Ви взяли що Ваші рішення - "не костилі"?

Судити про чуже ПО, не бачивши його, це, як би виразився пан NEP, те саме що "рассказывать про шумлеса, если вы никогда не были в лесу".

 

Да Вы молодец, я ничего не имею против. Просто о реалиях рассуждаю здесь с Вами.

 

Чем мониторите коммутаторы? Сколько портов опрашивается? 1000? 10000? 100000? 1млн?

[alex_o 1 194]

Ребята, я допетрил! Троль Юрий Бондарь - работник Киевстара. Этим логично объясняется почему у них реакция на жалобы абонентов идет неделями. Зато у них софт мега-крутой.

[Гайджин 574]

Здается мне, что его приосто плющит от собственной невъебности.

[Учумелые ручки 705]

Да Вы молодец, я ничего не имею против. Просто о реалиях рассуждаю здесь с Вами.

 

Чем мониторите коммутаторы? Сколько портов опрашивается? 1000? 10000? 100000? 1млн?

 

Это всё хорошо - но вот мы и приплыли ...

Мониторить 1 млн. портов на одной железке или группой железок - это бред сивой кобылы!!!

Для чего придумали сегменты? L2, L3? Агрегацию?

Нужно чётко разделять задачи а не сваливать всё в одну кучу ...

Некоторые уже доукрупнялись - теперь их перманентно колбасит не по детски уже который месяц ...

 

Меня добивает подход менеджмента который сеть хочет контролировать как мега корпорацию ....

 

Сеть изначально придумывалась как распределённая структура без единого (единственного) центра.

И сводить всё в один узел (в мега масштабах) - чревато и 2-3 дневными глобальными простоями и прочими радостями жизни.

 

Крупная сеть должна быть максимально расспределйнной, с резервными хоть кольцевыми линками,

с несколькими, распределёнными территориально, серверами доступа.

[Бонарь Юрий 13]

Ребята, я допетрил! Троль Юрий Бондарь - работник Киевстара. Этим логично объясняется почему у них реакция на жалобы абонентов идет неделями. Зато у них софт мега-крутой.

 

1. Не перекручивайте мою фамилию. Это как минимум оскорбительно.

2. Никакого отношения к киевстару не имею, и никогда не работал там

 

Мой личный опыт, моё ИМХО

 

Любая идея и практика имеет право на жизнь. Но есть более эфективные и менее.

[alex_o 1 194]

1. Не перекручивайте мою фамилию. Это как минимум оскорбительно.

Сорри! Спросоня попутался.

[onorua 126]

Интересно конечно читать как тут народ рассказывает про OSS/BSS, как будто это мега счастье, соединяя мух и котлеты в одном борще.

OSS - в простонародье - мониторинг сети, и всего что не связано с деньгами.

BSS - мониторинг денежных потоков, профайлы абонентов и т.д.

 

Как это работает у мобильных операторов:

OSS - есть мониторинг сети, всех служб, базы данных всего что не связанно с бизнес процессами. Этих людей называют в основном Оперейшенами. У многих это представляет собой 3-4 плазмы, на которых какой-то HP OpenView/Munin/Cacti пишет графики. Что-то упало - засветилось, заиграла музычка (Аларма). Оператор побежал по сети проверять и чинить. Работал не с одним мобильным оператором, всегда это выглядит именно так.

OSS - есть у многих уважающих себя провайдеров. Это и пинговалки и те же Cacti, Nagios, Zabbix.. упало - пришла СМСка, включил ноут - понеслась работа. Существенной разницы не вижу.

 

BSS - то чего нету у маленьких операторов, потому что им это нах@р не нужно. Что это такое, по простому - это все что связано с деньгами. Звонит вам абонент - у него перерасчет, это записывается скажем в репортинг базу, которую читает как правило данная Вендором биллинга хранимая процедура, и выдает - валидно не валидно. Так же есть фрод-мониторинг (он то есть и в банках и у мобильных операторов) Который собственно является основной фишкой BSS. Каждая транзакция проверяется на валидность, по сути это второй биллинг, только не риалтаймовый. Персонал там в основном толковые аналитики.

Для чего это нужно? У мобильных операторов много клиентов и много тарифов, если изначально все продумано и оттестировано, то со временем, конкурент выпускает еще один тариф, оператор терять бабло не хочет, выпускает свой тариф, новые акции и прочее.. народ начинает анализировать (я лично видел запрос на исправление ошибки в тарифе, по типу фрод, когда была упущена 1 секунда в полночь в одном тарифе, и народ умудрялся звонить именно в эту секунду и наговаривали тысячи). В Италии, во время плановых работ с биллингом пару лет назад, люди покупали припейдную карточку, звонили за границу по фолбекам (уходили в минус) и выбрасывали. Не нужно иметь семи пядей во лбу, если тебе выставляют счет за международный траффик в это время, что тебе нужно закрыть заграницу.

Вот это то что касается BSS.

 

Есть еще ITIL, как правило 3й мало кому нужно, но он необходим чтоб получить сертификат соответствия ISO. Так вот, для ITIL большие друзья делаю совершенно другие вещи, другие системы менеджмента и они не связаны с проприетарными OSS/BSS системами. Если много денег можно купить что-то от HP или Майкрософта. Они то есть, но не всегда все покупается за один день, а интегрируется постоянно друг с другом со временем. Все это, как бы вам не хотелось завернуть это в красивую обертку, объеденино в одну систему каким-то интегратором, который наваял прослоек на Яве и все типа работает. Тем кто не видел эти штуки в жизни, кажется что это манна небесная. По сути - это ничем не отличается от того что есть у вас. Я согласен - ITIL нужен, но не всем 3й. 2го достаточно для 99% случаев.

 

Для справки: основное отличие 3го от 2го в том, что 2й можно внедрять (и будет считаться что он внедрен) если есть хоть часть основных элементов (CMDB, единая точка входа .. ) 3й же требует внедрения всех элементов. Что для маленьких до 100к пользователей может быть вообще не нужно.

 

P.S. Когда я работал в команде маленького вендора для биллинга VoIP я думал что это ужасно, все на костылях. Люди же покупали и хвалили. Потом я перешел в большой биллинг GSM, и тут я увидел еще больше не понятных скажем так архитектурных моментов. Но люди покупают и это работает. Не нужно думать что то, что вы купили за большие деньги работает внутри ого-го как, пока вы не увидели код.

[_WesT_ 1 016]

Спасибо очень познавательно для меня.

[ВАК 99]

+1

Приятно когда грамотный человек пришел и толково пояснил, не выпендриваясь и не унижая окружающих.

[gsv 52]

Вообще, если по большому счету - то людям всеравно, какой там код, главное - юзабилити и багз-фри!

[onorua 126]

Я об этом и говорил. Просто человек выше, говорил о том что у коллег мол куча скриптов на костылях построенных. Я всего навсего сказал что это обычная практика, и даже мега продукты купленные за большие деньги - построены на тех же костылях, завернутые в обвертку "архитектуры". Если это работает, если это делает то что нужно конкретно человеку - зачем ему платить за то что, якобы, работает лучше. Если достаточно этого уровня. Просто мерятся, "а у тебя какой длины oss/bss" - как-то не спортивно. У каждого свои требования и у каждого свои задачи.

[Бонарь Юрий 13]

Интересно конечно читать как тут народ рассказывает про OSS/BSS, как будто это мега счастье, соединяя мух и котлеты в одном борще.

OSS - в простонародье - мониторинг сети, и всего что не связано с деньгами.

BSS - мониторинг денежных потоков, профайлы абонентов и т.д.

 

Как это работает у мобильных операторов:

OSS - есть мониторинг сети, всех служб, базы данных всего что не связанно с бизнес процессами. Этих людей называют в основном Оперейшенами. У многих это представляет собой 3-4 плазмы, на которых какой-то HP OpenView/Munin/Cacti пишет графики. Что-то упало - засветилось, заиграла музычка (Аларма). Оператор побежал по сети проверять и чинить. Работал не с одним мобильным оператором, всегда это выглядит именно так.

OSS - есть у многих уважающих себя провайдеров. Это и пинговалки и те же Cacti, Nagios, Zabbix.. упало - пришла СМСка, включил ноут - понеслась работа. Существенной разницы не вижу.

 

BSS - то чего нету у маленьких операторов, потому что им это нах@р не нужно. Что это такое, по простому - это все что связано с деньгами. Звонит вам абонент - у него перерасчет, это записывается скажем в репортинг базу, которую читает как правило данная Вендором биллинга хранимая процедура, и выдает - валидно не валидно. Так же есть фрод-мониторинг (он то есть и в банках и у мобильных операторов) Который собственно является основной фишкой BSS. Каждая транзакция проверяется на валидность, по сути это второй биллинг, только не риалтаймовый. Персонал там в основном толковые аналитики.

Для чего это нужно? У мобильных операторов много клиентов и много тарифов, если изначально все продумано и оттестировано, то со временем, конкурент выпускает еще один тариф, оператор терять бабло не хочет, выпускает свой тариф, новые акции и прочее.. народ начинает анализировать (я лично видел запрос на исправление ошибки в тарифе, по типу фрод, когда была упущена 1 секунда в полночь в одном тарифе, и народ умудрялся звонить именно в эту секунду и наговаривали тысячи). В Италии, во время плановых работ с биллингом пару лет назад, люди покупали припейдную карточку, звонили за границу по фолбекам (уходили в минус) и выбрасывали. Не нужно иметь семи пядей во лбу, если тебе выставляют счет за международный траффик в это время, что тебе нужно закрыть заграницу.

Вот это то что касается BSS.

 

Есть еще ITIL, как правило 3й мало кому нужно, но он необходим чтоб получить сертификат соответствия ISO. Так вот, для ITIL большие друзья делаю совершенно другие вещи, другие системы менеджмента и они не связаны с проприетарными OSS/BSS системами. Если много денег можно купить что-то от HP или Майкрософта. Они то есть, но не всегда все покупается за один день, а интегрируется постоянно друг с другом со временем. Все это, как бы вам не хотелось завернуть это в красивую обертку, объеденино в одну систему каким-то интегратором, который наваял прослоек на Яве и все типа работает. Тем кто не видел эти штуки в жизни, кажется что это манна небесная. По сути - это ничем не отличается от того что есть у вас. Я согласен - ITIL нужен, но не всем 3й. 2го достаточно для 99% случаев.

 

Для справки: основное отличие 3го от 2го в том, что 2й можно внедрять (и будет считаться что он внедрен) если есть хоть часть основных элементов (CMDB, единая точка входа .. ) 3й же требует внедрения всех элементов. Что для маленьких до 100к пользователей может быть вообще не нужно.

 

P.S. Когда я работал в команде маленького вендора для биллинга VoIP я думал что это ужасно, все на костылях. Люди же покупали и хвалили. Потом я перешел в большой биллинг GSM, и тут я увидел еще больше не понятных скажем так архитектурных моментов. Но люди покупают и это работает. Не нужно думать что то, что вы купили за большие деньги работает внутри ого-го как, пока вы не увидели код.

 

И да и нет. Но это Ваше ИМХО.

 

Вот задача и её возможно решение:

 

- есть сеть X состоит он из N участков. Допустим на участке N3 с 12.03.2013 с 17:00 до 18:00 будут проводится технические работы. Каким образом оперативно происходит уведомление абонентов? И какие люди, отделы(цепочка задействуется в этом)?

 

Еще одна задачка простая задачка:

 

- есть некий провайдер/оператор X с довольно обширной сетью. На одном из узлов N проводили технические работы либо подключали абонента. По халатности или незнанию или невнимательности один из монтажников переключил абонента А в другой порт. Насколько быстро об этом будет известно? И как будет устранена проблема? Сколько уйдет времени и будет задействовано людей, отделов.

 

Моя точка зрения такова:

 

- заканчиваются времена когда мелкие и средние провайдеры даже знать не хотели что такое вобще узел связи, как он должен быть оборудован, зачем нужен ввесь этот ITIL и т.д. Закончились времена низких затрат на обслуживание абонентов. Эффективное управление поможет сократить издержки и расходы.

 

И давайте раз уж так не ставить за пример крупных операторов. У них есть своя инфраструктура которая уже очень давно работает и возможно вней очень много недостатков но и в один момент всё переделать не получится. По этому там более длительные процессы модернизации и перехода к более новому.

[marek 16]

Вообще-то тему про использование той или иной системы нужно перекладывать в другую тему, а тут конкретно интересуют мнения по МТС. А про OSS/BSS, ITIL, ISO, ITSM и прочее можно прочитать и в энциклопедии.

[Бонарь Юрий 13]

Вообще-то тему про использование той или иной системы нужно перекладывать в другую тему, а тут конкретно интересуют мнения по МТС. А про OSS/BSS, ITIL, ISO, ITSM и прочее можно прочитать и в энциклопедии.

 

А пока уже нечего по МТС говорить.

 

Хотять выйти на рынок, но хотять с умом. А как получится увидим