![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovЗаказной пост для ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
tarantul: "Меня вот интересует вот какой вопрос. А как этот мегамоск под названием "процесс биллинга" программируется под необходимую логику?
Допустим пришел манагер, и сказал что надо тариф такой-то вот с такой-то логикой (дальше обычно идет что-то, что нормальному человеку в голову ни за что не придет). И что в этом случае делают люди саппортящие биллинг? Не переписывают же кусок кода для реализации этой "мечты идиота"?"
Короткий ответ: бывает по всякому - может быть и такое, что надо писать код.
Длинный ответ
Начну с определений терминов рейтинг и биллинг, которые я буду использовать. Очень часто их взаимно подменяют друг другом, и большой беды от этого не происходит, но в сегодняшний пост как раз затрагивает существенные и принципиальные различия между этими процессами, и я постараюсь их не путать :)
Итак, рейтинг - это процесс вычисления стоимости (rate) какого-то события. Договоримся, что событие - это акт потребления услгу пользователем в самом широком смысле этого слова :)
С рейтингом тесно связан биллинг - процесс формирования счетов, накладных и прочих бухгалтерских документов, выполнения "закрытия финансового периода", уведомления абонентов о их текущем балансе и задолженностях и прочих подобных танцев с бубнами.
Первое существенное различие между рейтингом и биллингом - это то, что биллинг - это неспецифичный для телекома процесс. Биллинг присутсвует и в компании, подающей в квартиры горячую воду, и на сайте www.livejournal.com (для платных аккаунтов), и во множестве других сервисных организаций.
Рейтинг же - процесс, специфичный для телеком-компаний. Провайдеры мобильной связи, провайдеры Internet, операторы фиксированных сетей - все они так или иначе реализуют у себя процесс рейтинга.
Кстати, по подобному критерию - специфичности для телекома - все информационные системы оператора мобильной связи часто делят на две категории - OSS (operator support systems) и BSS (business support systems). В OSS попадают вещи типа рейтинга, управления учетными записями абонента, а в BSS - вещи типа систем отчетности, систем управления предприятием (ERP), CRM-систем и т.п. (внимательный читатель мог заметить, что аббревиатура BSS применительно к оператору мобильной связи может иметь минимум два значения - business support system и base station subsystem. Это может служить (и зачастую - служит) поводом для мелких и не очень недопониманий)
Впрочем, я отвлекся. Вернемся к теме. Сегодня нас будет больше интересовать рейтинг, так как про биллинг я уже писал
Что такое рейтинг, и как его реализуют
Попробуем очутиться в шкуре архитектора или програмиста биллинговой системы.
Абстрактно говоря, рейтинг в мобильной связи есть функция, которой в качестве аргументов даются атрибуты события и атрибуты абонентов, принимавших в нем участие.
Самый популярный набор аргументов для функции рейтинга такой: тарифный план абонента А, номер абонента B, тип события, время события, длительность (Здесь и далее абонентом A (или A-party) я буду называть того, кто звонит, а абонентом B (B-party) того, кто принимает звонок.).
Самый популярный вид самой функции рейтинга: линейная зависимость (
Если мы договоримся, что стоимость у нас всегда линейно зависит от длительности, то это сильно упростит нам жизнь при написании системы. Мы, скорее всего, пойдем самым простым путем и получим ...
Табличный рейтинг (table-driven rating)
Сердцем нашей системы будет таблица, хранящая записи вида
Словом направлением называют телефонный номер или какую-то его часть - например, "звонки в Англию" часто называют "звонками на направление +44", а звонки в Киев - "звонками на направление +38044".
Соответственно, в нашей таблице могут быть записи типа
Как будет работать наш рейтинг? Очень просто. Берем запись о событии (call detail record, CDR) , из нее - номер абонента А. Находим его в базе абонентов. узнаем его тарифный план. Тип события нам известен, номер B - тоже (все это есть в CDR). Найдя в таблице тарифов запись с нужным направлением (для этого используют поиск самого длинного префикса, regexp match, glob match, ... ) , мы узнаем цену за секунду. Умножаем ее на длительность - и вуаля, рейтинг сделан!
Для такой системы, как правило, не является препятствием большое кол-во абонентов и одновременно большое кол-во тарифных планов. Единственное неудобство - GUI настройки такой системы, как правило, представляют из себя примитивный DB Grid, и при большом кол-ве тарифных планов их изменение превращается в отупляющую рутинную работу. Зато система Аццки Быстра(тм), что позволит нам на долгое время забыть о необходимости апгрейдить рейтинговые сервера :)
Впрочем, стоит заметить, что в дикой природе такие примитивные системы практически не встречаются - они или вымерли, или эволюционировали в ...
Табличный рейтинг, попытка номер 2
Заметим, что table-driven систему достаточно просто можно расширить возможностью задавать не только линейную зависимость стоимости от времени. Изменим схему нашей базы так: тарифы будут храниться в записях
Впрочем, жестко зашивать в коде бесплатный интервал в пять секунд - некрасиво. Добавим в нашу табличку полей -
Работать этот рейтинг будет чуть медленнее - для каждой записи надо будет не просто умножить два числа, а вызвать какую-то функцию. Но он все равно будет Аццки Быстр (тм). Во всем остальном (удобство конфигурирования, гибкость и т.п.) это решение будет идентично предыдущему.
Несмотря на кажущийся примитивизм, такие системы как правило и используются для рейтинга prepaid абонентов на IN-платформах. Самое большое ограничение этих систем - невозможность создания своих функций рейтинга и раз и навсегда определенный набор параметров, от которых может зависеть цена. Что приводит нас к ....
"Компонентный" рейтинг
Делаем еще один шаг по эволюционной лестнице. Дадим пользователю системы возможность самому писать функции рейтинга. Чтобы пользователи сильно не радовались, можно сделать этот процесс тяжелым, медленным, и тяжелоотлаживаемым. В лучшем случае, пользователю надо будет писать фукнции на PL/SQL, в худшем - писать их на внутреннем "скриптовом" языке, который представляет собой кастрированый C, в реальности им и является, и компилируется в DLL-и, вызываемые ядром рейтинга, которое, таким образом, будет с грохотом падать при любой серьезной ошибке в пользовательском коде.
Как вариант - пользователю можно не давать возможность что-то писать самому, зато он сможет выбирать из широкого набора доступных DLL-ек (компонент), покупать их у фирмы-производителя оптом или в розницу, и самостоятельно подключать к своему биллингу. Как это все будет настраиваться и конфигурироваться - слабонервным лучше не смотреть :)
Как правило, у подобных систем есть четко описанное API, через которое компоненты могут лазить в систему и извлечать оттуда нужные им данные. С целью сохранения пристойной производительности, через API дается доступ только к ограниченному подмножеству данных об абоненте, тарифном плане и т.п.
Таким образом, самым существенным ограничением подобной системы будет невозможность выйти за рамки этого API. Например, если через API нельзя получить дату подключения абонента, то нельзя будет сделать тарификацию вида "если вы с нами год - скидка 10%, если два - 20%, ..."
Rule-based рейтинг
Вариацией на ту же тему будет "рейтинг с возможностю написания правил" (rule-based). Пользователю дается внутренний язык описания правил рейтинга, с помощью которого, как правило, можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее.
Как правило, такие системы рейтинга являются частью (или тесно связаны с ) каких-то BSS-систем, и понятия, которыми оперируют BSS-системы, тоже могут быть доступны во время рейтинга.
Например, можно будет использовать в рейтинге сумму последнего счета (и рассчитывать на ее основании скидку) или же количество обращений абонента с жалобами в call center :)
Понятно, что такой рейтинг будет, пожалуй, самым медленным из всех. Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.
Что же делать, если система уже куплена, а маркетинг хочет странного?
Если маркетинг хочет странного - чего-то такого, что не реализуется в имеющейся системе рейтинга (а хочет он его, как правило, "на вчера"), то вариантов, как правило, немного.
0)Послать маркетинг. Я слышал, что бывают такие компании, в которых это возможно, но на практике с таким не встечался, и даже не видел людей, которые в таких компаниях работали.
1)Заказать изменение системы у поставщика. Как правило, это дорого, долго и означает геморрой с поддержкой решения в будущем.
2)Сделать какой-то костылик. Как правило, это быстро, дешено, и означает геморрой с поддержкой решения в будущем.
Какого рода костылик имеется в виду? Например, маркетинг хочет, чтобы каждый третий звонок абонента был бесплатным. "Правильное" решение - заказать у поставщика функциональность, которая позволит назначать каждому абоненту счетчики событий разных типов и возможность использовать значения этих счетчиков в рейтинге. Допустим, это занимает три месяца, а функциональность нужна уже через 5 дней, т.к. надо опередить ближайших конкурентов, которые, по слухам, собираются предложить что-то подобное.
Универсальный костыль выглядит так: пишется программка, в которую попадают все CDR-ы непосредственно перед рейтингом. Эта программа ведет и обновляет таблицу
Например, можно в каждом третьем звонке дописывать к номеру абонента B префикс "666", а систему рейтинга сконфигурировать так, чтобы все звонки на направление 666 были бесплатными. Маленький update базы перед биллингом не позволит префиксу попасть в детальные распечатки абонентов :)
Или же можно превращать каждый третий звонок в событие какого-то нового типа, и в рейтинге проставлять всем событиям такого типа нулевую стоимость.
Вариантов - масса. Каждый оператор имеет свой "стиль" и свой любимый набор костылей, который он холит, лелеет и растит. Периодически совокупная масса костылей превышает критическую, и происходит смена биллинговой системы на другую (или апгрейд на новую версию), в процессе чего костыли убираются и реализуются "правильным" образом. После чего процесс создания костылей начинается заново - по неизведаной доселе причине рынку нужны именно те функции, которых нет в текущей используемой версии биллинговой системы :)
Вот, где-то так.
PS
Надеюсь, никого не тошнит от смены дизайна журнала? :)
tarantul: "Меня вот интересует вот какой вопрос. А как этот мегамоск под названием "процесс биллинга" программируется под необходимую логику?Допустим пришел манагер, и сказал что надо тариф такой-то вот с такой-то логикой (дальше обычно идет что-то, что нормальному человеку в голову ни за что не придет). И что в этом случае делают люди саппортящие биллинг? Не переписывают же кусок кода для реализации этой "мечты идиота"?"
Короткий ответ: бывает по всякому - может быть и такое, что надо писать код.
Длинный ответ
Начну с определений терминов рейтинг и биллинг, которые я буду использовать. Очень часто их взаимно подменяют друг другом, и большой беды от этого не происходит, но в сегодняшний пост как раз затрагивает существенные и принципиальные различия между этими процессами, и я постараюсь их не путать :)
Итак, рейтинг - это процесс вычисления стоимости (rate) какого-то события. Договоримся, что событие - это акт потребления услгу пользователем в самом широком смысле этого слова :)
С рейтингом тесно связан биллинг - процесс формирования счетов, накладных и прочих бухгалтерских документов, выполнения "закрытия финансового периода", уведомления абонентов о их текущем балансе и задолженностях и прочих подобных танцев с бубнами.
Первое существенное различие между рейтингом и биллингом - это то, что биллинг - это неспецифичный для телекома процесс. Биллинг присутсвует и в компании, подающей в квартиры горячую воду, и на сайте www.livejournal.com (для платных аккаунтов), и во множестве других сервисных организаций.
Рейтинг же - процесс, специфичный для телеком-компаний. Провайдеры мобильной связи, провайдеры Internet, операторы фиксированных сетей - все они так или иначе реализуют у себя процесс рейтинга.
Кстати, по подобному критерию - специфичности для телекома - все информационные системы оператора мобильной связи часто делят на две категории - OSS (operator support systems) и BSS (business support systems). В OSS попадают вещи типа рейтинга, управления учетными записями абонента, а в BSS - вещи типа систем отчетности, систем управления предприятием (ERP), CRM-систем и т.п. (внимательный читатель мог заметить, что аббревиатура BSS применительно к оператору мобильной связи может иметь минимум два значения - business support system и base station subsystem. Это может служить (и зачастую - служит) поводом для мелких и не очень недопониманий)
Впрочем, я отвлекся. Вернемся к теме. Сегодня нас будет больше интересовать рейтинг, так как про биллинг я уже писал
Что такое рейтинг, и как его реализуют
Попробуем очутиться в шкуре архитектора или програмиста биллинговой системы.
Абстрактно говоря, рейтинг в мобильной связи есть функция, которой в качестве аргументов даются атрибуты события и атрибуты абонентов, принимавших в нем участие.
Самый популярный набор аргументов для функции рейтинга такой: тарифный план абонента А, номер абонента B, тип события, время события, длительность (Здесь и далее абонентом A (или A-party) я буду называть того, кто звонит, а абонентом B (B-party) того, кто принимает звонок.).
Самый популярный вид самой функции рейтинга: линейная зависимость (
a * x + b) стоимости от длительности события, где коэффициент 'a' берется из тарифного плана, а 'b' - так называемая "плата за соединение" (call setup fee). (кстати, стоит отдельно рассказыать, откуда у нее растут ноги или нет?)Если мы договоримся, что стоимость у нас всегда линейно зависит от длительности, то это сильно упростит нам жизнь при написании системы. Мы, скорее всего, пойдем самым простым путем и получим ...
Табличный рейтинг (table-driven rating)
Сердцем нашей системы будет таблица, хранящая записи вида
(rating_plan_id, event_type, destination, price_per_unit). Каждая запись будет описывать, почем стоит секунда звонка (или call forward-а, или 1 sms, ...) на указанное направление в указанном тарифном плане. Словом направлением называют телефонный номер или какую-то его часть - например, "звонки в Англию" часто называют "звонками на направление +44", а звонки в Киев - "звонками на направление +38044".
Соответственно, в нашей таблице могут быть записи типа
("Супер-шара", "звонок", "*", 0.01) - в тарифном пакете "Супер-шара" звонки куда угодно - по копейке секунда :)Как будет работать наш рейтинг? Очень просто. Берем запись о событии (call detail record, CDR) , из нее - номер абонента А. Находим его в базе абонентов. узнаем его тарифный план. Тип события нам известен, номер B - тоже (все это есть в CDR). Найдя в таблице тарифов запись с нужным направлением (для этого используют поиск самого длинного префикса, regexp match, glob match, ... ) , мы узнаем цену за секунду. Умножаем ее на длительность - и вуаля, рейтинг сделан!
Для такой системы, как правило, не является препятствием большое кол-во абонентов и одновременно большое кол-во тарифных планов. Единственное неудобство - GUI настройки такой системы, как правило, представляют из себя примитивный DB Grid, и при большом кол-ве тарифных планов их изменение превращается в отупляющую рутинную работу. Зато система Аццки Быстра(тм), что позволит нам на долгое время забыть о необходимости апгрейдить рейтинговые сервера :)
Впрочем, стоит заметить, что в дикой природе такие примитивные системы практически не встречаются - они или вымерли, или эволюционировали в ...
Табличный рейтинг, попытка номер 2
Заметим, что table-driven систему достаточно просто можно расширить возможностью задавать не только линейную зависимость стоимости от времени. Изменим схему нашей базы так: тарифы будут храниться в записях
(rating_plan_id, event_type, destination, function_id), где function_id - указание на одну из нескольких жестко прошитых в коде системы функций. Такой апгрейд позволит нам, например, создавать тарифные планы с фиксированной стоимостью звонка или планы вида "первые пять секунд - бесплатны".Впрочем, жестко зашивать в коде бесплатный интервал в пять секунд - некрасиво. Добавим в нашу табличку полей -
(rating_plan_id, ..., function_id, const_1, const_2, const_3, const_4, ..., const_9). После этого мы сможем писать в ней ("МегаДрайв", "звонок", "*", "Фикс_цена_с_беспл_интервалом", 5, 10, NULL, NULL, ..., NULL), что будет означать, что в тарифном плане "МегаДрайв" все звонки стоят 10 рублей, независимо от стоимости, причем первые пять секунд - бесплатно.Работать этот рейтинг будет чуть медленнее - для каждой записи надо будет не просто умножить два числа, а вызвать какую-то функцию. Но он все равно будет Аццки Быстр (тм). Во всем остальном (удобство конфигурирования, гибкость и т.п.) это решение будет идентично предыдущему.
Несмотря на кажущийся примитивизм, такие системы как правило и используются для рейтинга prepaid абонентов на IN-платформах. Самое большое ограничение этих систем - невозможность создания своих функций рейтинга и раз и навсегда определенный набор параметров, от которых может зависеть цена. Что приводит нас к ....
"Компонентный" рейтинг
Делаем еще один шаг по эволюционной лестнице. Дадим пользователю системы возможность самому писать функции рейтинга. Чтобы пользователи сильно не радовались, можно сделать этот процесс тяжелым, медленным, и тяжелоотлаживаемым. В лучшем случае, пользователю надо будет писать фукнции на PL/SQL, в худшем - писать их на внутреннем "скриптовом" языке, который представляет собой кастрированый C, в реальности им и является, и компилируется в DLL-и, вызываемые ядром рейтинга, которое, таким образом, будет с грохотом падать при любой серьезной ошибке в пользовательском коде.
Как вариант - пользователю можно не давать возможность что-то писать самому, зато он сможет выбирать из широкого набора доступных DLL-ек (компонент), покупать их у фирмы-производителя оптом или в розницу, и самостоятельно подключать к своему биллингу. Как это все будет настраиваться и конфигурироваться - слабонервным лучше не смотреть :)
Как правило, у подобных систем есть четко описанное API, через которое компоненты могут лазить в систему и извлечать оттуда нужные им данные. С целью сохранения пристойной производительности, через API дается доступ только к ограниченному подмножеству данных об абоненте, тарифном плане и т.п.
Таким образом, самым существенным ограничением подобной системы будет невозможность выйти за рамки этого API. Например, если через API нельзя получить дату подключения абонента, то нельзя будет сделать тарификацию вида "если вы с нами год - скидка 10%, если два - 20%, ..."
Rule-based рейтинг
Вариацией на ту же тему будет "рейтинг с возможностю написания правил" (rule-based). Пользователю дается внутренний язык описания правил рейтинга, с помощью которого, как правило, можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее.
Как правило, такие системы рейтинга являются частью (или тесно связаны с ) каких-то BSS-систем, и понятия, которыми оперируют BSS-системы, тоже могут быть доступны во время рейтинга.
Например, можно будет использовать в рейтинге сумму последнего счета (и рассчитывать на ее основании скидку) или же количество обращений абонента с жалобами в call center :)
Понятно, что такой рейтинг будет, пожалуй, самым медленным из всех. Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.
Что же делать, если система уже куплена, а маркетинг хочет странного?
Если маркетинг хочет странного - чего-то такого, что не реализуется в имеющейся системе рейтинга (а хочет он его, как правило, "на вчера"), то вариантов, как правило, немного.
0)Послать маркетинг. Я слышал, что бывают такие компании, в которых это возможно, но на практике с таким не встечался, и даже не видел людей, которые в таких компаниях работали.
1)Заказать изменение системы у поставщика. Как правило, это дорого, долго и означает геморрой с поддержкой решения в будущем.
2)Сделать какой-то костылик. Как правило, это быстро, дешено, и означает геморрой с поддержкой решения в будущем.
Какого рода костылик имеется в виду? Например, маркетинг хочет, чтобы каждый третий звонок абонента был бесплатным. "Правильное" решение - заказать у поставщика функциональность, которая позволит назначать каждому абоненту счетчики событий разных типов и возможность использовать значения этих счетчиков в рейтинге. Допустим, это занимает три месяца, а функциональность нужна уже через 5 дней, т.к. надо опередить ближайших конкурентов, которые, по слухам, собираются предложить что-то подобное.
Универсальный костыль выглядит так: пишется программка, в которую попадают все CDR-ы непосредственно перед рейтингом. Эта программа ведет и обновляет таблицу
(номер абонента A, кол-во звонков), и модифицирует CDR-ы с каждым третьим звонком таким образом, чтобы потом можно было "заметить" эту модификацию в системе рейтинга и поставить звонку нулевой тариф.Например, можно в каждом третьем звонке дописывать к номеру абонента B префикс "666", а систему рейтинга сконфигурировать так, чтобы все звонки на направление 666 были бесплатными. Маленький update базы перед биллингом не позволит префиксу попасть в детальные распечатки абонентов :)
Или же можно превращать каждый третий звонок в событие какого-то нового типа, и в рейтинге проставлять всем событиям такого типа нулевую стоимость.
Вариантов - масса. Каждый оператор имеет свой "стиль" и свой любимый набор костылей, который он холит, лелеет и растит. Периодически совокупная масса костылей превышает критическую, и происходит смена биллинговой системы на другую (или апгрейд на новую версию), в процессе чего костыли убираются и реализуются "правильным" образом. После чего процесс создания костылей начинается заново - по неизведаной доселе причине рынку нужны именно те функции, которых нет в текущей используемой версии биллинговой системы :)
Вот, где-то так.
PS
Надеюсь, никого не тошнит от смены дизайна журнала? :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-11-26 03:42 am (UTC)(no subject)
Date: 2006-11-26 03:44 am (UTC)(no subject)
Date: 2006-11-26 02:10 pm (UTC)В доме стоит счетчик, в него суется смарт-карта, на которой "деньги". Раз в месяц карточку надо вытащить и отнести на почту/представительство компании/etc, где ее "зарядят" деньгами, после чего ты ее несешь домой и снова втыкаешь в счетчик, который и занимается рейтингом :)
(no subject)
Date: 2006-11-26 06:33 am (UTC)от нового дизайна тошнит.
(no subject)
Date: 2006-11-26 02:08 pm (UTC)Все равно обратно на Digital Multiplex я не уползу - из него что-то сделали совсем непотребное. Буду колоться, плакать, и продолжать грызть этот кактус :)
(no subject)
Date: 2006-11-26 07:01 am (UTC)В Лаках регулярно посылаем маркетинг.:) Разумеется, когда он хочет каких-то нереальных извратов.
По рассказам народа из Кисты, там это тоже регулярно происходит. Доказывается, что такое невозможно на текущей базе, после чего вопрос переходит в политическую плоскость. Через пару лет, при глобальном апгрейде всего, может, что-то и изменится.
(no subject)
Date: 2006-11-26 02:15 pm (UTC)Хорошо вам, по-доброму завиду :)
(no subject)
Date: 2006-11-26 07:03 am (UTC)Кстати, как зовётся эта схема?
(no subject)
Date: 2006-11-26 02:06 pm (UTC)Зовется стиль "smooth sailing", и переполз я на него после того, как с Digital Multiplex (OSWD) сделали что-то странное, и он у меня оброс непонятными кнопками и цветными полосками :(
(no subject)
Date: 2006-11-26 08:31 am (UTC)****** Скупая мужская слеза прокатилась по щеке консультанта SAP BW (хранилище данных от SAP).
(no subject)
Date: 2006-11-26 02:31 pm (UTC)Зато там (в BW) прикольные часики. Навозюкаешь кучу ETL-правил, нажмешь Apply, а оно тебе пишет "analyzing ... generating code .... compiling ..."
Мы шутили, что на фазе generating code оно засылает результаты анализа в индию, и там индийские программисты быстро-быстро пишут код на ABAP-е :)
(no subject)
Date: 2006-11-26 03:27 pm (UTC)(no subject)
Date: 2006-11-26 08:51 am (UTC)Особенно эти "костыли".
И как у вас там всё ещё не сломалось окончательно? :)
(no subject)
Date: 2006-11-26 02:32 pm (UTC)(no subject)
Date: 2006-11-26 03:19 pm (UTC)(no subject)
Date: 2006-11-26 09:41 am (UTC)Просто вопрос - в Москве МТС таким образом коменсирует правило "входящие бесплатно"...
(no subject)
Date: 2006-11-26 02:32 pm (UTC)(no subject)
Date: 2006-11-26 09:41 am (UTC)(no subject)
Date: 2006-11-26 02:33 pm (UTC)(рассудительно)
Date: 2006-12-15 05:24 pm (UTC)Целиком портируется на платформу земного биоценоза hive вместе с Королевой. И дальше - по Всем Известному Сценарию: первое поколение манагеров питается найденными личинками клиентов и выдаёт на гора мйод, второе - откармливает трутней и Королеву, поток мйода наружу уменьшается, а потом прекращается; при жизнни третьего служба маркетинга закукливается, защищаясь от недовольных клиентов и начинает жить за счёт хозяев пасеки, откачивая мйод обратно. После чего случается коллапс техпроцесса и развал компании, маркетинг Роится и разлетается по новым местам обитания. Где цикл повторяется снова.
Re: (рассудительно)
Date: 2006-12-16 06:45 pm (UTC)Распечатаю и повешу на стенку.
Распечатай, распечатай...
Date: 2006-12-16 06:58 pm (UTC)(no subject)
Date: 2006-11-26 11:17 am (UTC)(no subject)
Date: 2006-11-26 02:35 pm (UTC)(no subject)
Date: 2006-11-26 02:53 pm (UTC)(no subject)
Date: 2006-11-26 03:27 pm (UTC)(no subject)
Date: 2006-11-26 03:39 pm (UTC)(no subject)
Date: 2006-11-28 06:09 pm (UTC)(no subject)
Date: 2006-11-29 10:12 am (UTC)(no subject)
Date: 2006-11-29 04:47 pm (UTC)Вот и приходится по ЖЖ искать информацию:))))))))))))))))))))))))))
(no subject)
Date: 2006-11-29 10:10 pm (UTC)Так что возможность есть, дело - за желанием :)
(no subject)
Date: 2006-11-26 12:04 pm (UTC)(no subject)
Date: 2006-11-26 02:34 pm (UTC)(no subject)
Date: 2006-11-26 03:45 pm (UTC)(no subject)
Date: 2009-05-21 05:45 pm (UTC)(no subject)
Date: 2009-06-18 07:09 pm (UTC)Хранение в БД тарифов по дополнительным услугам
Date: 2007-01-16 03:09 pm (UTC)Затем появляется новая услуга, н-р, IPTV или игровые сервера. Для пользования ими есть несколько тарифов со своими параметрами (н-р, первый тариф-абонплата за доступ к просмотру видео или второй тариф-без абонплаты, но n руб за час просмотра).
Вопрос, как это реализовать в БД. Дополнить существующую таблицу тарифов данными об доп. услугах или создать новую таблицу для них? В первом случае не известно, что ставить для уже подключенных клиентов в поля для доп тарифов и число их увеличится в геометрической прогрессии. Во втором случае придется немного менять логику работы программ рейтинга.
Вопрос, как это правильно реализовать и предусмотреть возможность появления новых услуг.
(no subject)
Date: 2007-03-02 09:32 am (UTC)А чем плох этот способ? "можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее". Или это "слишком сложно"(tm) для пользователей? Или все-таки здесь под пользователями имелись в виду "программисты со стороны заказчика\поддержальщики"?
в худшем - писать их на внутреннем "скриптовом" языке, который представляет собой кастрированый C, в реальности им и является, и компилируется в DLL-и, вызываемые ядром рейтинга, которое, таким образом, будет с грохотом падать при любой серьезной ошибке в пользовательском коде.
А почему DLL? Это обычно подоконное?? И разве нельзя достаточно запросто изолировать "ядро рейтинга" от "пользовательского кода", чтобы "с грохотом падал" только последний?
Вариацией на ту же тему будет "рейтинг с возможностю написания правил" (rule-based). Пользователю дается внутренний язык описания правил рейтинга, с помощью которого, как правило, можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее.
Опять -- здесь "пользователь" == "программист", или же "конечный пользователь"? Ибо если это не конечных пользователь, то никак не могу понять, зачем "заниматься мышкованием"(с)??
Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.
По-поводу "навозюкивания мышкой в ... GUI" вспоминается Business Objects...
(no subject)
Date: 2007-03-20 10:05 pm (UTC)Конечно же второе. Плюс, я ж говорю - это лучший случай, встречающийся не так уж и часто.
Нет, не подоконное. Можно вместо DLL написать .so - суть от этого не поменяется. Изолировать, безусловно, можно, но конечный результат будет ровно один - неработающий рейтинг.
Плюс, качество кода в коммерческом софте даже такого уровня - ниже плинтуса, пишут его зачастую студенты, и изоляция, какой бы очевидной она не выглядела, с большой вероятностью сделана не будет :)
Да, это программист. Да, это нельзя понять. Добро пожаловать в наш клуб.
Каждый второй, а то и вообще каждый вендор так и норовит сделать настройку business process rules исключительно через возюкание мышой. В лучшем случае, делают export/import в XML, к которому можно написать свой (де)компилятор в/из чего-то, похожего на нормальный язык.
(no subject)
Date: 2007-03-21 07:27 am (UTC)Все-таки "неработающий рейтинг" лучше чем "неработающая система" (когда рейтинг, падая, тянет за собой все остальное).
Каждый второй, а то и вообще каждый вендор так и норовит сделать настройку business process rules исключительно через возюкание мышой.
Почему??? Или ответ только один: "Да, это нельзя понять"?
(no subject)
Date: 2007-03-21 09:16 pm (UTC)Ну, это больше из серии "больной перед смертью потел? Это хорошо!".
Почему??? Или ответ только один: "Да, это нельзя понять"
Я могу только догадываться, что это потому, что:
1)Это Модный Тренд
2)Это проще продать менеджерам, которые ездят на разные выставки и т.п.
3)Это лучше смотрится в паверпойнтовских презентациях
4)Даже примитивная логика приобретает такой вид, что можно запугать кого угодно нагромождением квадратиков и стрелочек
5)Такой ГУЙ внушает топ-менеджменту обманчивое чувство простоты и управляемости "даже обезьяной", что стимулирует выработку мыслей о снижении ТСО и возбуждает покупательный рефлекс.
6)Когда юзер ограничен 4-5 действиями, его проще валидировать, контролировать и т.п.
Где-то так.