?

Log in

dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
Как настраивают/программируют рейтинг и биллинг. 
26th-Nov-2006 03:14 am
Заказной пост для 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
Надеюсь, никого не тошнит от смены дизайна журнала? :)
Comments 
26th-Nov-2006 03:42 am (UTC)
Теперь понятно почему коммунизм развалился. Рейтинг был нулевой.
26th-Nov-2006 03:44 am (UTC)
Кстати, у поставщиков горячей воды тоже может быть рейтинг. Ключевые слова: экономия, перерасход.
26th-Nov-2006 02:10 pm (UTC)
Кстати, да - в Англии я видел, как работает prepaid-рейтинг воды.

В доме стоит счетчик, в него суется смарт-карта, на которой "деньги". Раз в месяц карточку надо вытащить и отнести на почту/представительство компании/etc, где ее "зарядят" деньгами, после чего ты ее несешь домой и снова втыкаешь в счетчик, который и занимается рейтингом :)
26th-Nov-2006 06:33 am (UTC)
Интерестно, спасиб.

от нового дизайна тошнит.
26th-Nov-2006 02:08 pm (UTC)
А можно развить тему - что не так с дизайном? Впрочем, да, несколько все сливается в кучу (/me меняет цвета и делает шрифты больше ...)

Все равно обратно на Digital Multiplex я не уползу - из него что-то сделали совсем непотребное. Буду колоться, плакать, и продолжать грызть этот кактус :)
26th-Nov-2006 07:01 am (UTC)
> 0)Послать маркетинг. Я слышал, что бывают такие компании, в которых это возможно, но на практике с таким не встечался, и даже не видел людей, которые в таких компаниях работали.

В Лаках регулярно посылаем маркетинг.:) Разумеется, когда он хочет каких-то нереальных извратов.

По рассказам народа из Кисты, там это тоже регулярно происходит. Доказывается, что такое невозможно на текущей базе, после чего вопрос переходит в политическую плоскость. Через пару лет, при глобальном апгрейде всего, может, что-то и изменится.
26th-Nov-2006 02:15 pm (UTC)
В Лаках регулярно посылаем маркетинг.:) Разумеется, когда он хочет каких-то нереальных извратов.

Хорошо вам, по-доброму завиду :)

26th-Nov-2006 07:03 am (UTC)
Дизайн вполне нормальный. Глазам не больно, постоянного превышения ширины экрана (как в моём) не происходит.
Кстати, как зовётся эта схема?
26th-Nov-2006 02:06 pm (UTC)
Я вот сделал еще шрифты побольше и цвета перетянул со старой схемы - по идее, должно было стать еще веселее, нет?

Зовется стиль "smooth sailing", и переполз я на него после того, как с Digital Multiplex (OSWD) сделали что-то странное, и он у меня оброс непонятными кнопками и цветными полосками :(
26th-Nov-2006 08:31 am (UTC)
Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.

****** Скупая мужская слеза прокатилась по щеке консультанта SAP BW (хранилище данных от SAP).
26th-Nov-2006 02:31 pm (UTC)
Знаем, плавали (немножко) :)

Зато там (в BW) прикольные часики. Навозюкаешь кучу ETL-правил, нажмешь Apply, а оно тебе пишет "analyzing ... generating code .... compiling ..."

Мы шутили, что на фазе generating code оно засылает результаты анализа в индию, и там индийские программисты быстро-быстро пишут код на ABAP-е :)
26th-Nov-2006 03:27 pm (UTC)
Я уже рыдаю. :)
26th-Nov-2006 08:51 am (UTC)
Кошмар какой, госп-ди.
Особенно эти "костыли".
И как у вас там всё ещё не сломалось окончательно? :)
26th-Nov-2006 02:32 pm (UTC)
А у нас под каждый костыль есть мощная Подпорка (tm). Вот на них все и держится :)
26th-Nov-2006 03:19 pm (UTC)
Да-да. Служба Техничного Упора :))
26th-Nov-2006 09:41 am (UTC)
А про call setup fee рассказать можно. Существуют ли реальные затраты и/или услуги здесь?
Просто вопрос - в Москве МТС таким образом коменсирует правило "входящие бесплатно"...
26th-Nov-2006 02:32 pm (UTC)
ОК, напишем :)
26th-Nov-2006 09:41 am (UTC)
Интересно, а откуда берутся маркетологи, работающие у мобильных операторов? Ибо это есть отдельная тема... :)
26th-Nov-2006 02:33 pm (UTC)
Я думаю, что как в фильме "Чужие", где-то в джунглях Амазонки есть разбившийся космический корабль и кладка зародышей... Вот отуда, как из инкубатора, и бедется 50% маркетологов :)
15th-Dec-2006 05:24 pm (UTC) - (рассудительно)
Ну, зачем же кладка...
Целиком портируется на платформу земного биоценоза hive вместе с Королевой. И дальше - по Всем Известному Сценарию: первое поколение манагеров питается найденными личинками клиентов и выдаёт на гора мйод, второе - откармливает трутней и Королеву, поток мйода наружу уменьшается, а потом прекращается; при жизнни третьего служба маркетинга закукливается, защищаясь от недовольных клиентов и начинает жить за счёт хозяев пасеки, откачивая мйод обратно. После чего случается коллапс техпроцесса и развал компании, маркетинг Роится и разлетается по новым местам обитания. Где цикл повторяется снова.
16th-Dec-2006 06:45 pm (UTC) - Re: (рассудительно)
Вах! Прелестно, просто прелестно :)

Распечатаю и повешу на стенку.
16th-Dec-2006 06:58 pm (UTC) - Распечатай, распечатай...
А по прочтении - съешь !
ПОМНИ
Они Уже В изде !
 
Я со своим маркетингом могу уже нормально общаться только с Королевой. Остальные - что твои птицеяды: восемь глаз и все на затылке, человечьему языку не обучены и при любом случае норовят цапнуть хелицерами за руку, их кормяшу. И непрерывно генерят креатифф ! Верный признак, шо пиздец не за горами.
 
А так хотелось завершить опутывать паутиною Системы весь ореал обитания клиентегов...
26th-Nov-2006 11:17 am (UTC)
Работая некогда в крупном операторе связи (не сотовом), неоднократно посылал маркетинг в дальние дали, одновременно тыкая носом в техзадание на биллинговую систему. ;-)
26th-Nov-2006 02:35 pm (UTC)
Типа, они же это техзадание и писали/подписывали?
26th-Nov-2006 02:53 pm (UTC)
Именно. А потом было длительное согласование со всеми заинтересованными сторонами и наконец, все скреплялось "большой круглой печатью" (С). После этого, общение с маркетологами становилось легким и приятным. ;)
26th-Nov-2006 03:27 pm (UTC)
Опытный маркетинг на такое не ведется и говорит: "наше дело - придумывать, куда движется бизнес, а ваше дело - строить рельсы и паровоз. причем - в указанные сроки" :)
26th-Nov-2006 03:39 pm (UTC)
Обратно, опытный IT на такое не ведется. ;)
28th-Nov-2006 06:09 pm (UTC)
:)
29th-Nov-2006 10:12 am (UTC)
Вы, барышня, не улыбайтесь, а расскажите нам, почему (цитирую) "по неизведаной доселе причине рынку нужны именно те функции, которых нет в текущей используемой версии биллинговой системы" :)
29th-Nov-2006 04:47 pm (UTC)
ну почему же причина неизведана? Если комментировать данную цитату относительно конкретной отдельно взятой компании N, то основная проблема - это техническая безграмотность маркетологов, так как зачастую они не знают перечень ВСЕГО, на что способна текущая биллинговая система и что бы эдакое, отличное от конкурента, предложить рынку. Поэтому придумывают из головы оригинальные (ну, по-крайней мере, им так кажется:) хотелки, которые, конечно же, не всегда возможно легко, просто и дешево удовлетворить в рамках существующих функциональностей. НО: не особо-то с ними делятся информацией о возможностях систем, как правило, это происходит только в ответ на четко поставленный вопрос:) с четко приставленным раскаленным утюгом:))))
Вот и приходится по ЖЖ искать информацию:))))))))))))))))))))))))))
29th-Nov-2006 10:10 pm (UTC)
Кстати, даю хинт - некоторое время тому некто ДА и МК провели "вечер на арене" отвечая на вопросы СС. Говорят, что СС остался(лось) довольным :)

Так что возможность есть, дело - за желанием :)
26th-Nov-2006 12:04 pm (UTC)
А расскажи еще пожалуйста про языки программирования, на которых биллинги/рейтинги пишут. Про индусов, про студентов, про всех-всех-всех :)
26th-Nov-2006 02:34 pm (UTC)
А эту тему уже застолбили. Будет отдельный пост "правда ли, что все биллингописатели - такие идиоты, какими кажутся?" :)
26th-Nov-2006 03:45 pm (UTC)
Не, бывает и хуже :)
21st-May-2009 05:45 pm (UTC)
И где же он? Или я что-то пропустил?
18th-Jun-2009 07:09 pm (UTC)
Еще не было - я про него забыл :)
16th-Jan-2007 03:09 pm (UTC) - Хранение в БД тарифов по дополнительным услугам
Anonymous
Спасибо за обзор, интересно было прочитать. Появились некоторые вопросы по теме. Представим ситуацию, когда есть определенные тарифные планы по основной услуге (н-р, подсчет интернет-трафика или еще чего-то), в которых учитываются различные параметры (время получения услуги, абонплата итд). Все это хранится в одной таблице Тарифы с полями Идентификатор тарифа, Абонплата, Цена единицы потребленной услуги днем, Цена единицы потребленной услуги ночью...
Затем появляется новая услуга, н-р, IPTV или игровые сервера. Для пользования ими есть несколько тарифов со своими параметрами (н-р, первый тариф-абонплата за доступ к просмотру видео или второй тариф-без абонплаты, но n руб за час просмотра).
Вопрос, как это реализовать в БД. Дополнить существующую таблицу тарифов данными об доп. услугах или создать новую таблицу для них? В первом случае не известно, что ставить для уже подключенных клиентов в поля для доп тарифов и число их увеличится в геометрической прогрессии. Во втором случае придется немного менять логику работы программ рейтинга.
Вопрос, как это правильно реализовать и предусмотреть возможность появления новых услуг.
2nd-Mar-2007 09:32 am (UTC)
В лучшем случае, пользователю надо будет писать фукнции на PL/SQL,

А чем плох этот способ? "можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее". Или это "слишком сложно"(tm) для пользователей? Или все-таки здесь под пользователями имелись в виду "программисты со стороны заказчика\поддержальщики"?

в худшем - писать их на внутреннем "скриптовом" языке, который представляет собой кастрированый C, в реальности им и является, и компилируется в DLL-и, вызываемые ядром рейтинга, которое, таким образом, будет с грохотом падать при любой серьезной ошибке в пользовательском коде.

А почему DLL? Это обычно подоконное?? И разве нельзя достаточно запросто изолировать "ядро рейтинга" от "пользовательского кода", чтобы "с грохотом падал" только последний?

Вариацией на ту же тему будет "рейтинг с возможностю написания правил" (rule-based). Пользователю дается внутренний язык описания правил рейтинга, с помощью которого, как правило, можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее.

Опять -- здесь "пользователь" == "программист", или же "конечный пользователь"? Ибо если это не конечных пользователь, то никак не могу понять, зачем "заниматься мышкованием"(с)??

Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.

По-поводу "навозюкивания мышкой в ... GUI" вспоминается Business Objects...
20th-Mar-2007 10:05 pm (UTC)
Или это "слишком сложно"(tm) для пользователей? Или все-таки здесь под пользователями имелись в виду "программисты со стороны заказчика\поддержальщики"?
Конечно же второе. Плюс, я ж говорю - это лучший случай, встречающийся не так уж и часто.

А почему DLL? Это обычно подоконное?? И разве нельзя достаточно запросто изолировать "ядро рейтинга" от "пользовательского кода", чтобы "с грохотом падал" только последний?
Нет, не подоконное. Можно вместо DLL написать .so - суть от этого не поменяется. Изолировать, безусловно, можно, но конечный результат будет ровно один - неработающий рейтинг.

Плюс, качество кода в коммерческом софте даже такого уровня - ниже плинтуса, пишут его зачастую студенты, и изоляция, какой бы очевидной она не выглядела, с большой вероятностью сделана не будет :)

Опять -- здесь "пользователь" == "программист", или же "конечный пользователь"? Ибо если это не конечных пользователь, то никак не могу понять, зачем "заниматься мышкованием"(с)??
Да, это программист. Да, это нельзя понять. Добро пожаловать в наш клуб.

Каждый второй, а то и вообще каждый вендор так и норовит сделать настройку business process rules исключительно через возюкание мышой. В лучшем случае, делают export/import в XML, к которому можно написать свой (де)компилятор в/из чего-то, похожего на нормальный язык.

21st-Mar-2007 07:27 am (UTC)
Изолировать, безусловно, можно, но конечный результат будет ровно один - неработающий рейтинг.

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

Каждый второй, а то и вообще каждый вендор так и норовит сделать настройку business process rules исключительно через возюкание мышой.

Почему??? Или ответ только один: "Да, это нельзя понять"?
21st-Mar-2007 09:16 pm (UTC)
Все-таки "неработающий рейтинг" лучше чем "неработающая система" (когда рейтинг, падая, тянет за собой все остальное).

Ну, это больше из серии "больной перед смертью потел? Это хорошо!".

Почему??? Или ответ только один: "Да, это нельзя понять"

Я могу только догадываться, что это потому, что:
1)Это Модный Тренд
2)Это проще продать менеджерам, которые ездят на разные выставки и т.п.
3)Это лучше смотрится в паверпойнтовских презентациях
4)Даже примитивная логика приобретает такой вид, что можно запугать кого угодно нагромождением квадратиков и стрелочек
5)Такой ГУЙ внушает топ-менеджменту обманчивое чувство простоты и управляемости "даже обезьяной", что стимулирует выработку мыслей о снижении ТСО и возбуждает покупательный рефлекс.
6)Когда юзер ограничен 4-5 действиями, его проще валидировать, контролировать и т.п.

Где-то так.
This page was loaded Jul 25th 2017, 8:36 pm GMT.