Ни для кого не секрет, что я работаю в банке и волей судеб связан с CRM-системой Siebel (от Oracle). Перед этим, работая в консалтинге, я много разного повидал, но все крутилось вокруг одного — банковской розницы. Банковская розница — это различного рода кредиты физическим лицам (т.е. не организациям), а также пластиковые карты. Потребительские кредиты на покупку тостера и монитора, ипотека, автокредиты на желанный пепелац — это все, чем я занимаюсь с высоты банковского IT.
Сегодня с Юрой мы обсуждали одну айтишную хохму, жутко написанное техническое задание, ТЗ на жаргоне. А в течение дня мне попались еще пара словесно запутанных формулировок от бизнес-заказчика. Теперь к главному.
В любой CRM-системе есть ключевые сущности, вокруг которых "пляшут" все остальные. Так вот, в розничном кредитовании, почти вне зависимости от платформы, есть по крайней мере 4 (прописью: четыре) сущности, которые являются столпами, и которые трогать без фундаментальных причин запрещается, — это Клиент, Заявка, Договор и Анкета. Первые три обычно уже есть в системе (если разработчики этой системы не идиоты) и так или иначе "ложатся" на текущие требования бизнеса, включая переход из второй в третью по определенной модели принятия решения. А вот четвертый зверь — это выдумка российского законодательства, которое обязывает Банк хранить электронную версию печатной анкеты клиента, заполняемой клиентом собственноручно. То есть в системе надо хранить без искажений всю информацию, которую он указал о себе, своих родственниках, местах работы, учебы, источниках доходов и расходов и прочем. Хранить скан документа бестолку, потому что этими данными потом руководствуются риск-аналитики и служба безопасности на этапе рассмотрения заявки (анкета "прикрепляется" к заявке). Поэтому в системе создается незаконнорожденный ребенок в виде сущности "Анкета клиента" (или нечто похожее).
На эту дурацкую анкету, которая отбирает здоровье у всего IT-отдела одним махом, завязаны и другие полезные вещи, а именно — АБС, система противодействия мошенничеству, скоринг- и fraud-оценки (и стоящие за этими оценками специализированные системы), эмиссия (для пластиковых карт) и куча другого не менее важного. Отсюда мораль — любая (и это не шутка, действительно любая, то есть каждая) заявка от бизнеса на изменение системы должна быть проанализирована на предмет возможного внесения изменений в анкету. Ели аналитик проворонит внесение этих изменений, и ему согласуют ТЗ бизнес-заказчики (которым абсолютно пофиг, что и как там у айтишников устроено; после согласования дергаться будет поздно), то аналитику грозит публичная пенетрация от остальной части отдела и гарантированный геморрой от 14-часового рабочего дня по этому ТЗ.
Так что будьте начеку, друзья.
Ну а вот собственно выдержка из того ТЗ:
ОтветитьУдалить"Если дата начала действия записи файла позднее даты окончания действия записи справочника с датой начала действия ранее даты начала действия записи файла, дата окончания действия записи файла ранее даты начала действия записи справочника, которая позднее даты начала действия записи файла, и дата окончания действия записи файла или записи справочника непустые, то контроль пересечения дат включённых и условно включённых записей КБК пройден успешно."
А родная головная шведская Нордеа своим софтом/наработками не делится, или все настолько завязано на рашкинские законы, что бестолку?
ОтветитьУдалитькак это все знакомо.
ОтветитьУдалитьhttp://img0.liveinternet.ru/images/attach/c/0/33/355/33355301_1223394063_sdlc.jpg
2 ohnesta.at:
ОтветитьУдалитьСофтом не делится, ибо уже есть Сибель, а наработки по бизнес-процессам в большинстве случаев без толку, ибо, как было сказано, наши законы такие законы...
2 RRi
ОтветитьУдалитьРит, на самом деле немного не так, но некоторое "концептуальное сходство" все же есть ))