Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Бизнес-аналитика

Какие ошибки совершает аналитик в первые полгода работы и как их избежать

19.05.2021 14:18:09 | Автор: admin

Хайди хо, Кайл!

Меня зовут Диана и я бизнес-аналитик в компании Surf. В прошлом году я закончила бакалавриат факультета компьютерных наук в ВГУ: это дало мне базовые теоретические знания. Однако теория мало применима без практики: теперь набиваю шишки в настоящих проектах.

Я пришла к вам для того, чтобы поделиться опытом, который получила на своём первом боевом проекте. Мы делали банковское мобильное приложение со сложной архитектурой и кучей фич.

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

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

Не бойтесь задавать больше вопросов и просить уточнений

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

Лучше задать больше вопросов, чем что-то упустить. Например, когда работаешь над проектом, важно уточнить:

  • На чьей стороне будет реализована логика: фронта, middleware, бэка?

  • Как определять нужное состояние элемента? Как и где получать и обрабатывать нужные параметры?

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

  • Касаются ли вашей стороны эти требования или от вас никаких доработок и не потребуется?

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

Проверяйте и перепроверяйте выполнение договорённостей

Когда в процессе проработки фичи участвует большое количество человек, это как минимум значит, что сторонам будет непросто договориться. А ещё это значит, что сложно будет уследить за всеми требованиями и договорённостями.

Например, на моем проекте в обсуждении новой функциональности могут участвовать проджект-менеджеры и бизнес-аналитики со стороны команд фронта и бэка, продакт-оунеры и тестировщики со стороны заказчика.

Обычно мы обсуждаем задачи в переписке или на онлайн-митингах. Нетрудно понять, что на созвоне в 20 человек легко пропустить какое-то поручение. Поэтому я записываю основную информацию, которую обсудили во время созвона. После дублирую требования в печатном виде и прошу подтверждения у коллег, чтобы убедиться, что ничего не упустила. Кроме того зафиксированные в письменном виде договорённости гарантируют, что заказчик не сможет при желании переобуться и поменять требования.

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

Не стесняйтесь быть настойчивым и даже назойливым, иногда вы и проджект-менеджер единственные, кто может повлиять на то, что договорённости будут выполнены в срок. Если видите, что ответов нет в оговоренное время, не стесняйтесь пинговать коллег. Иначе ожидание может сильно затянуться.

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

Пример из жизни

Мы разрабатывали фичу, которая при выполнении определённого условия отображала кнопку на главном экране. Когда обсуждали реализацию, решили, что условие будет проверяться на бэке, а фронт будет получать поле с признаком выполнения или невыполнения этого условия.

Я не акцентировала внимание бэкендеров и продакт оунера на том, насколько важно, чтобы бэк присылал нам этот признак. Когда фича должна была уже уйти в разработку, этого признака всё ещё не было и в помине, потому что ни бэк, ни сторонний сервис, к API которого мы обращались, не разработали его.

Из-за этого процесс задержался ещё на неделю, потому что пришлось потратить много времени на повторное обсуждение. В итоге решили кнопку отображать всегда:)

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

Уточняйте, как сделать проще

Бывает, что бизнес-аналитику реализация фичи кажется удобной. Он предлагает её разработчику, а в ответ получает: Чё-то сложно, давай по-другому?. Это нормально: взгляды аналитика и разработчика на реализацию фичи могут разительно отличаться: разработчик понимает, что ему хотят втюхать что-то сложное и заморочное, и идёт в отказ.

Если бизнес-аналитику не хватает опыта, чтобы оценить, насколько сложен вариант реализации, лучше сразу прийти к разработчикам и посоветоваться с ними. Иначе потом придется проходить новый круг ада: обсуждать изменения. Кроме того, это может сдвинуть сроки реализации: не нужно объяснять, почему это плохо:)

Френдли ремайндер

Если встаёт вопрос, на чьей стороне должна быть реализована сложная логика, связанная со сравнениями, вычислениями, сортировкой и так далее, практически всегда логичнее вынести её на бэк. Запомните мой совет и повторяйте его как мантру на всех созвонах (и перед сном).

Будьте внимательным к потенциально проблемным требованиям

Если на этапе верхнеуровневой аналитики чуйка шепчет вам, что требования могут перерасти из маленькой задачи на день в большую и неповоротливую фичу не игнорируйте эти сигналы и не спускайте всё на тормозах, мол, прорвёмся. Обычно я составляю большой список вопросов к заказчику и к бэку по требованиям, где прописываю, правильно ли я поняла формулировку.

Уточните (если нужно, несколько раз), правильно ли вы поняли, что ваша задача просто добавить картинку котика на экран. Может оказаться, что добавить нужно обязательно чеширского кота, а ещё он должен улыбаться в момент, когда вы моргаете. Я специально привела утрированный пример.

А вот пример из жизни. Недавно мы параллельно вели две фичи от разных продакт-оунеров. Фичи были частично взаимосвязаны, но требования во многих местах противоречили друг другу. Каждый продакт видел UI по-своему: договориться было достаточно трудно. Тогда пришлось столкнуть их лбами. После этому мы наконец пришли к варианту, устраивающему всех.

Важно быть начеку и проверять, не противоречат ли новые требования уже реализованной функциональности.

Помните, что есть много требований, которые могут быть не видны не вооруженным опытом взглядом под толщей воды из документа с требованиями. Хорошая новость: чем опытнее становится бизнес-аналитик, тем больше потенциально проблемных мест он видит и тем тщательнее терзает заказчика вопросами и уточнениями. Поэтому сделайте глубокий вдох и наберитесь терпения! Дальше лучше.

Как определить, что перед вами задача-оборотень, которая может превратиться из человечной в дикую? По количеству непоняток. Берегитесь, если:

  • Нет точной информации, как обрабатывать значения, каким образом и где они будут вычисляться, как их подставлять и отображать.

  • Не очевидна инициализация флоу и переход между экранами.

  • Нет четкого понимания логики.

Например, несколько месяцев назад мы начали обсуждение фичи без определённых требований. У продакт-оунера не было четкого понимания, что должно получиться в итоге. Это стоило нам многих часов созвонов-обсуждений и несколько раз перекроенного ТЗ.

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

Пример

Прилетают требования: нужно определять значение поля по параметрам, которые будут приходить с сервера. Значение поля должно отображаться в интерфейсе.

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

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

_______

Я описала только малую часть ошибок, с которой может столкнуться начинающий бизнес-аналитик. Многие ошибки вам ещё предстоит совершить самим в любом случае. Однако я постаралась поподробнее описать процессы взаимодействия и общения в реальном проекте. Надеюсь, это поможет вам легче влиться в проект.

Вот и всё, мои маленькие хоббиты. Я поделилась с вами своей мудростью, теперь вы сами по себе. Не дрейфте, не теряйтесь, будьте настойчивы и внимательны. В добрый путь!

Подробнее..
Категории: Программирование , Анализ и проектирование систем , Аналитика мобильных приложений , Аналитика , Советы начинающим , Мобильная разработка , Блог компании surf , Surf , Опыт , Бизнес-аналитика , Советы , Бизнес аналитик

Облом, или как провалился любимый ИТ-проект

20.07.2020 20:10:45 | Автор: admin
Его пример другим наука

Предисловие


Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 100 процентов. И почему все кончилось обломом, я до сих пор толком не понимаю.

За свою жизнь айтишника я участвовал в разработке многих успешных проектов. Большинство из них были сравнительно простыми по идее и посредственными по реализации. Справедливости ради, упомяну об исключении выдающемся, на мой взгляд, проекте. Он был совершенно неординарным по замыслу(замысел был со стороны высокопоставленного банковского экономиста) и хороший по реализации. Реализовали его мы на ассемблере. Базой данных служили файлы прямого и последовательного доступа. Проект успешно эксплуатировался.
Однажды, участвуя в очередной посредственной разработке операционного дня банка, я столкнулся с необходимостью вычисления некоторых показателей, значения которых регламентировалось национальным банком. Это уже выходило за рамки дебета и кредита бухгалтерского учета. А я к этому времени прочитал книги Экономикс(автор Кэмпбелл и др.) и Деньги( автор Долан), и приступил к книге Микроэкономика(автора не помню, но зарубежный). Все это и послужило рождению идеи аналитики, как некоего аналога медицинской аналитики. Должны быть определены все показатели, достаточно полно отображающие состояние бизнеса. Это значит должны быть заданы точные правила вычисления показателей и реализован механизм их вычисления и использования. В идеале так и виделись работники с экранами, на которых отображалось текущее и прогнозное состояние дел, за которые отвечает работник. А работник задает вопросы типа:
  • А почему такой скачок у такого-то показателя?
  • А кто совершил такую-то операцию?
  • А что будет с состоянием, если совершить такую-то операцию?
  • А что будет с состоянием, если изменить такие-то показатели на такие-то значения?

И т.д.
И работник на основании всего этого принимает решения. Неужели кто-то откажется от таких перспектив? Ведь это настоящее современное рабочее место для творческого экономиста и менеджера.
В конце концов проект был реализован. И я наивно думал, что пройдет он на ура. Ведь кончилось время директивного управления, и значит нужен механизм, позволяющий держать руку на пульсе бизнеса(Я даже думал дать проекту название Бизнес-Пульс). А что случилось, увидим далее.
Я влюбился в проект и был в спокойной уверенности в его успехе. Но, увы Надеюсь, что, хотя-бы для начинающих разработчиков, иcтория будет полезной.

История проекта


Скоро сказка сказывается, да не скоро дело делается
Все названия фирм и банков не настоящие.

Фирма М. Начало


В М я участвовал в проекте валютного операционного дня банка(ОДБ). И тут я столкнулся с началами аналитики. Пришли нормативные документы, в которых определялись разнообразные нормативы деятельности коммерческого банка и регламент их применения. Нормативы определяли рамки риска для деятельности банка. И тут у меня, вдохновленного переводными книгами по экономике(упаси боже, было читать советские книги по экономике), забрезжила идея Аналитики проекта, позволяющего пользователю определять и рассчитывать любые экономические показатели и контролировать их на соблюдение нормативных или других ограничений. Я поговорил с руководителями(а это были три дамы: президент, председатель, директор!!!), но не убедил их в нужности самостоятельного проекта. И я фактически оказался не у дел и мне стало и скучно и грустно. Но тут мне предложили подработать на стороне разработать проект мультивалютного операционного дня банка(ОДБ) для фирмы НП. Я стал работать и в конце концов перешел в НП на постоянную основу разрабатывать проект мультивалютного ОДБ. Но задумка аналитики осталась в душе.

Фирма НП. Скромное продолжение


Итак, в НП я разрабатываю мультивалютный ОДБ. Помня о нормативах, упомянутых в предыдущем пункте, я их реализовал и подцепил к справке, которая выдавала определение показателя, формулу его вычисления и текущее значение. Все это было реализовано в лоб без всякой унификации и глубокой системы. Вот в Москве проходит очередная выставка банковских продуктов. И мы выставляемся. Подходит к нам одна банкирша и начинает знакомиться с нашим продуктом. Скоро звучит вопрос: А как у вас дела с нормативами?. Я ей показываю таблицу текущих значений нормативов, она нажимает F1 и тут появляется определение норматива и формула его вычисления. Она была безмерно приятно удивлена, заявив, что ни у кого похожего не видела. И тут я укрепился в идее об аналитике. Если уж решение в лоб для нескольких показателей приятно удивило клиента, то что будет, если ему дать настоящую продвинутую бизнес-аналитику. В общем, я еще более воодушевился.

Банк БСБ. Личное систематическое начало


Как-то я демонстрировал в банке БСБ свой проект валютного операционного дня. Автоматизацией в БСБ ведал мой бывший шеф из банка ПСБ. Он посмотрел проект, попил со мною пару раз кофе и пригласил на работу к себе. А мы уже внедряли проект в одном из банков. А я, увы, внедрять был не очень охоч. И я согласился на переход. И вот я в БСБ. С работой справлялся быстро и было много свободного времени. Начал осваивать Delphi. Ознакомился с эксплуатируемыми задачами в банке. Оказался целый конгломерат разнотипных задач. Каждая автономна и со своим подходом. Я еще раз понял, что нужна единая банковская аналитика. Работаю над ней по собственной инициативе. Набросал концепции и начала техпроекта и обращаюсь с задумкой к шефу. Но как раз шеф набирает кадры из вычислительного центра ПСБ и они показывают некие зачатки банковской аналитики, которой они пользовались в ПСБ. Все реализовано на Oracle Discovery. А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили. Но я продолжаю разрабатывать проект самостоятельно. Времени хватало. Я самообразовываюсь читаю толстые книги: Управление финансами в коммерческих банках(автор Синки), Банковский менеджмент(автор Роуз), Финансовое управление фирмой(автор Смит и др. ). И еще больше укрепляюсь в своей идее.
Когда я уже ушел из БСБ, то узнал, что БСБ склоняется к мысле приобрести SAP, что в итоге и сделали. Потом несколько лет внедряли, и я уже не знаю внедрили ли. Да, было модно обращаться к западным продуктам. Объяснение простое: ведь это означало систематические зарубежные командировки за счет банка.
Меня продолжает вередить зуд аналитики. И вот я решил продвинуть ее на частном примере кредитования. Кратко о сути задачи. Есть портфель кредитных заявок. В общем случае весь портфель удовлетворить нельзя: может не хватить обеспечивающих ресурсов. Плюс ко всему есть набор нормативов, которым должно удовлетворять состояние банка. Значит есть проблемы выбора. А где есть несколько вариантов выбора, там возникает задача оптимального выбора. Критерий оптимизации может быть разным, например:
  • Интегральная процентная прибыль за некоторый период
  • Чистая приведенная стоимость выбора за тот же период

Дело осложняется тем, что каждый клиент характеризуется некоторым риском. Значит критерий должен взвешиваться по вероятности возврата кредита. Мне удалось свести задачу к задаче линейного программирования. Риск по клиенту задавался моделью эмпирического риска, которую пришлось разработать самому. Сложность представляли нормативные ограничения, которые задавались нелинейными формулами. Оказались, что они только по форме нелинейные и тождественными простыми преобразованиями их можно свести к линейным. Риск можно было задавать и априорно.
Итак, постановка сделана. Нужно получить в банке одобрение проекта. Иду к руководству. Руководство не может само оценить предложенные идеи и меня посылают в какой-то полунаучный отдел(забыл точное название) и я попадаю на консультацию к кандидату экономических наук, бывшему нархозовцу(институт народного хозяйства). Не знаю почему, но тот сразу ополчился против и понеслись фразы типа i,j все писать умеют. В подтексте слышится: Пришли тут неостепененные и Суди дружок не выше сапога. И никак ему не втолковать, что проект не претендует на науку, а предлагает конкретную разработку и алгоритм под неё, так что можно приступать к программированию. Но это никак не втолковать. В итоге никаких рекомендаций я не получил. Ну и фиг с вами. Пусть все будет как есть. Это был второй раз, когда я встретился с отраслевой наукой и второй раз я попал к ней на рога.

Фирма МРЦ. Личное систематическое продолжение


Шеф уходит возглавлять МРЦ. Он забирает меня с собой. Фирма денежная и может финансировать несколько проектов. Я начинаю зондировать разработку проекта бизнес-аналитики. Продолжаю делать наброски технического проекта. Разрабатываю средствами CASE структуру БД. И тут мне опять представился случай проявить инициативу. Полным ходом идет разработка системы RTGS(Real Time Gross Settlement) реализации в реальном времени крупных платежей. Проект курируется Европой. Регулярно приезжают холеные европейские консультанты, которых мы угощаем растворимым кофе из нехоленых ржавых банок. Регулярно в Европу ездит наше руководство. Обслуживает руководство переводчики из моего управления. И у меня в управлении стоит целый книжный шкаф ценных переводов по банковской проблематике. Большинство из них я не могу уразуметь, то ли из-за сложности тематики, то ли из-за качества перевода. Ну хорошо, разрабатывается RTGS. А что делать с мелкими платежами? Предполагается, что они будут реализовываться в режиме клиринга. На клиринг нет ни постановки, ни вразумительной терминологии. И вот я берусь самостоятельно разрабатывать проект Клиринг. Разрабатываю словарь терминов и приступаю к техническому проекту. Словарь даю на обозрение широкой публике. Энтузиазм из меня так и прет.
Но тут наступают новые политические времена. Арестовывают Винникову, председателя Нацбанка РБ. А мой шеф возглавил МРЦ по представлению Винниковой. И вот началось выдавливание всех, кто прямо или косвенно был связан с Винниковой. Шеф увольняется. И меня начинают прессовать. Даже сослали в дальнюю от моего управления маленькую комнатку. Приходит новый начальник. Я ему несу на рассмотрение свой проект клиринга. Начальник держит проект у себя около месяца. Я ждал, ждал и обращаюсь к нему. А в ответ услышал: Разработка проекта не входит в Ваши прямые должностные обязанности. Вот вам и инициатива. Я прошу вернуть проект. Начальник мнется, мнется, но все-таки возвращает проект мне и проект до сих пор пылится у меня на балконе. Да, кстати, по теме клиринга я написал в отраслевой журнал статью. В ней предлагалась модель, определяющая временной лаг клиринга, оптимизирующий использование ресурсов клиринга. Статью приняли и напечатали без всяких препонов. Воодушевленный я развил идею дальше и понес в журнал вторую статью. И тут по поведению редактора я понял, что канал перекрыт. И мне стало ясно, что пора сваливать самому, не ожидая пока попросят. Обращаюсь к фирме СК и предлагаю проект аналитики. Тут же получаю приглашение на работу. Значит, я на правильном пути.

Фирма СК. Начало венчурного финансирования


Итак, я в СК и руководитель проекта Zero. Это проект банковской аналитики. Кроме руководителя пока нет никого. Пока один. Начинаю реализацию на Дельфи. Проходит месяца три и меня вызывает технический директор и просит ознакомить его с состоянием проекта. Знакомлю. Уже кое-что есть. А директор говорит: А почему бы не перейти на самоокупаемость продавать проект по частям, которые уже реализованы? Я опешил. Начинаю возражать, что мол МАЗ не продает колеса, а продает самосвалы. Попикировались и разошлись.
Начинаю чувствовать пристальное внимание со стороны главного инженера. Это был мой непосредственный начальник. Вся проектная идеология исходила от него. Человек талантливый и с жесткими взглядами на управление и с мягкими пряниками похвалы. Он все время зондирует мои дела и однажды объяснился. Он разработал интерпретатор подмножества Паскаля и все банковские отчеты главного продукта фирмы делались на скриптах этого интерпретатора. Скрипты назывались ОПР, не помню почему. Так вот, сказал он проект нужно делать на ОПР и вся аналитика должна сводиться к отчетам, написанными на ОПР. Это был еще не приказ(а он, конечно, имел право приказать). Мы начали дискутировать. Я как плюсы своего подхода приводил объектный подход и гораздо более систематический подход к показателям вплоть до их кодирования и подход к аналитике не как к отчетам, а как к моделированию экономических ситуаций и анализу последствий моделирования. В общем была приятная нормальная дискуссия. Такие дискуссии продолжались несколько раз. Это хорошо, это правильно. Но, однако, ни он ни я не меняем свою точку зрения. Тогда босс предлагает организовать публичный диспут, в котором каждая из сторон представит свой список аргументов. Отлично. Но в день дискуссии я узнаю, что босс вмещался в мой список и скорректировал его на свой вкус с позиции начальства и представил исправленный список публике. Это меня шокировало. Ведь ты как начальник мог приказать мне работать так как ты считаешь нужным и я, или должен принять это, или уволиться. Но если свободная дискуссия, то не затыкай мне рот. Мы на равных. В общем диспут я проиграл, хоть и не с разгромным счетом. Бодался теленок с дубом. Я получил хороший урок корпоративной этики и стал искать новую фирму. И нашел АТЛ.

Фирма АТЛ. Конец венчурного финансирования


И тут, наконец, я получаю карт-бланш для любых фаз разработки. И разрешение на набор команды. Но когда я еще один работал, босс уже пригласил потенциальных клиентов на просмотр продукта. И вот банкир из Казахстана изъявляет желание приобрести проект. Хорошо, что босс спросил у меня готов ли я. Я отказался от внедрения: cамому разрабатывать и самому внедрять не слишком ли. И я стал набирать команду. Больше 8 человек в бригаде никогда не было. Каждому человеку давался приличный самостоятельный кусок проекта. Я составлял на него ТЗ и вперед. Через месяц, два становилось очевидным годится ли человек.
Итак, проект стал развиваться быстрыми темпами. Некоторые функции подсказывали потенциальные клиенты. Например, я демонстрирую проект французам. Дошел до графиков динамических рядов. И тут один француз спрашивает: А вы не скажете, почему в прибыли тут такой скачок?. И тут же мелькает мысль: Как это я, дурак, сам не додумался задать себе такой вопрос?. В результате появилась операционная декомпозиция набор всех операций, изменяющих заданный показатель в заданное время. А с операции можно выйти и на ее исполнителя.
Хранение и обработка динамических рядов, сценарное моделирование, виртуальные показатели, статистическая проверка гипотез, регрессии, поиск наилучших регрессий, обработка портфеля финансовых инструментов, разного рода декомпозиции значений показателей, разного рода компараторы все реализовывалось на мой взгляд быстро. Проект становился все солиднее. Я попробовал ради интереса реализовать Web-интерфейсы для создания Web-служб. Это оказалось несложным, но далее web-тематику мы не развивали.
Начали выставляться на ИТ-выставках. Я демонстрировал не презентацию, а реальную работу продукта. Позже я от этого отказался, так как это слишком большой стресс. У меня даже руки стали дрожать, когда нужно было реально продемонстрировать требуемое свойство. Интерес к продукту был и немаленький. Из одного солидного банка пришло ИТ-руководство. На следующий день пришла целая бригада из ИТ-департамента. Потом пришла бригада банкиров. А мне все показывай им. Ну думаю, дело на мази. Увы. А в большинстве приходили ИТ-шники. И до того дотошно расспрашивали, что однажды я прямо спросил: Так вы намереваетесь брать или просто так интересуетесь? А в ответ: Да нет, брать мы не будем, мы просто тоже делаем что-то подобное и поэтому интересуемся как дела у других. Я взял и напросился посмотреть их проект. Не отказали. Проект был реализован на java. Он имел дело только с генерацией показателей. И эта генерация занимала на мой взгляд слишком много времени. И, поэтому, генерация шла в ночное время.
Однажды прекрасным весенним выходным днем меня вызывают на работу. Нужно показать проект важному банкиру из Питера. Проект банкиру очень понравился и он попросил приехать в Питер и показать проект широкой публике. Едем. Присутствует весь менеджмент банка. Нас представили и тут до представления начались бурные дискуссии между менеджерами. Одна партия за существующий там проект, а вторая за нас. Мы слушали, слушали и попросили прервать дебаты. Мол, мы покажем проект, а потом дебатируйте. Так и сделали. В итоге решили, что мы переведем всю БД нашего проекта на питерский Progress, сохранив то, что уже есть в нем и дополнительно в рамках нашего проекта реализуем несколько новых функций. Потом все это мы покажем и далее решится судьба проекта. Мы реализовали то, что требуется и собираемся в командировку в Питер. И вот пришло время ехать. И тут шеф дает отбой. Что и почему, я так и не узнал, так как не был посвящен в бизнес-интриги. И Питер обломился.
Были посетители и из Парижа. Глава делегации был какой-то потомок русских эмигрантов. Русский он знал неплохо. Судя по всему, проект ему понравился и он в знак уважения(?) подарил мне ноутбук от IBM., правда не совсем последней модели. Ноутбук и сейчас работает. Вскоре шеф приказывает мне готовить проект для Парижа. Вот это да! Перевели на французский всю документацию. Локализовали проект. Обмениваемся данными с банком в Париже. Готовимся к командировке. И тут шеф говорит, что наш покровитель переходит на повышение в другую фирму, не связанную с нашей тематикой И все затихло.
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев прохлада со стороны банкиров. Да и вид у всех типа Кому нужно дополнительная работа без дополнительной оплаты. В конце концов мой знакомый при очередной встрече за рюмкой и обсуждению текущего политического момента произнес сакраментальную фразу При такой политике не нужно аналитики.

Векселя


И тут представилась возможность реализовать маленькое подмножество аналитики на примере обработки векселей. Работа с субъектами полностью была взята из аналитики. Ну, и несколько показателей пригодились также. Быстро реализуем проект Векселя. Проект внедрен. Идет сопровождение. И тут грянул гром. В контрольные органы поступила кляуза, что на проекте отмыты деньги, а проект не делает то что нужно(Похоже дело было в том, что у нас работал сын заказчика проекта Векселя). И вот мы разработчики должны продемонстрировать проект ревизору. Хорошо, что мы детально изложили ТЗ и четко реализовали все пункты ТЗ в проекте. Продемонстрировали ревизору работу проекта по всем пунктам ТЗ. Придраться было не к чему. А проект стоил мизерные деньги и как на нем можно было нажиться не представляю. По крайней мере мы на нем не нажились.
Проект был спасен и мы уже подумывали о его развитии. Но тут президент запретил вексельную форму расчетов. И хотя нас просили сохранить всю инфраструктуру проекта(работа с субъектами хозяйствования), но о деньгах речь не шла и нам не было резона трудиться.

Поиск криминала


А тут подвернулся еще один проект, который можно и нужно было связать с аналитикой. Объявился интересный потенциальный заказчик. Он описывает нам предмет автоматизации примерно так. Есть множество субъектов и множество отношений между ними. Нужно определить прямые и производные атрибуты, которые характеризуют степень финансовой криминальности субъекта и на основании атрибутов криминальности выявлять подозрительных субъектов и отслеживать их. Предполагаемый заказчик говорил только, что нужно вести досье и дело на каждого клиента, а также собирать сведения о всех отношениях субъекта. Основные поставщики данных: МВД, банки, налоговые органы, собес, таможня, интерпол
Начались дебаты разрабатывать ли самим или брать покупной продукт. Заказчик склонялся к покупному варианту. Оно и понятно: зарубежные командировки, красивая реклама продуктов(сами продукты не имели демоверсий и их нельзя было реально пощупать), а деньги бюджетные, чего их считать. Я начал разрабатывать ТЗ. Скоро понял, что вряд ли оно будет завершено. Дело в том, что мой новый шеф пытался добиться того чтобы все документы, структуры, файлы были определены на стадии ТЗ. Фактически он хотел втиснуть в ТЗ техпроект. Вдобавок, каждое решение должно было протоколироваться за подписью заказчика и разработчика. Поэтому по каждому пункту ТЗ собирались совещания с заказчиком. Я высказал свои сомнения в успехе подобного подхода и стал параллельно по собственной инициативе разрабатывать самостоятельный проект на Дельфи. Мне было просто интересно. Основная информационная структура ориентированный нагруженный граф отношений. Узлы графа субъекты, ребра графа отношения, нагруженные типом, размером, датой начала отношений, датой активации отношения В графе могут быть различные поиски: цепочки однородных отношений, цепочки неоднородных отношений, цепочки заданной длины, циклы, цепочки отношений, с размерами превышающими заданный лимит и т.д. и т.п. Разработал соответствующие классы и сравнительно быстро реализовал проект. Я продемонстрировал его руководителю предполагаемого проекта поиска криминала. На нескольких десятках тысяч субъектов, сотен тысяч отношений, десятка полтора типов отношений, любая цепочка находилась примерно за секунду. А буквально на следующий день руководитель сказал, что заказчик прекратил с нами отношения. Как и следовало ожидать, дальше ТЗ дело не пошло. А прошло около года. Мораль: не нужно слишком взнуздывать заказчика. А может шеф и не хотел этого проекта. Дело в том, что он был ответственен и за проект ERP для КГБ, а проект горел
А я, работая с отношениями, заинтересовался языком Prolog, точнее Visual Prolog. Начал пробовать. И удивительно, если в Дельфи реализация поиска цепочек требовала немалых усилий и размера программ, в Прологе это делалось компактной декларацией. Вот что значит заточенность языка на проблему и его декларативность. Описание предметной области декларативно и поэтому оно сравнительно легко ложилось в декларации Пролога.
Но не очень понравились возможности Visual Prolog по выводу форм. И у меня забрезжила мысль, что каждой специфичной проблеме нужен свой язык. Язык проектирования и генерации отчетов, язык проектирования ввода данных, язык проектирования вывода данных, язык коммуникаций, язык обработки отношений, язык обработки списков, язык описания данных, язык бизнес-аналитики, язык размещения сервисов и управления ими, язык бухучета, Короче, нужны не универсальные, а предметно-ориентированные языки. Дело только в стандартизации интерфейсов между получаемыми модулями. Зачем мне вся мощь C# с Visual Studio, если я, например, разрабатываю только формы, или только отчеты, или только обмен с БД,
Проект был включен в аналитику в подсистему Отношения.

Отступление о технических писателях


Когда я стал работать с вышеозначенным руководителем(он также бывший физик), тот стал жаловаться, что никто из его молодых подчиненных не в состоянии толком написать документацию. Я вполне с ним согласился и всю документацию по своим проектам писал сам. Вплоть до презентаций на Powerpoint.
Теперь мне кажется, что проблема технического писательства еще более обострилась. Люди стали мало читать, а пишут только интернет-комментарии, которые иногда стыдно читать.
Какой язык самый главный? твой родной. Его нужно знать в первую очередь.

Попытка интеграции


Проектом интересуются, но проект не покупается. Я заволновался и стал искать причины. А в то время главным банковским ИТ-продуктом на рынке был операционный день банка(ОДБ). И я решаю расширить рамки проекта и сделать интегрированный проект, включающий в себя: ОДБ, кадры, депозиты, кредиты, натуральный учет, операционный учет. Шефа долго не пришлось уговаривать. С ОДБ дела пошли удовлетворительно. А вот с кредитами и депозитами получился конфуз. Дело в том, что кадры на эти проекты мне не пришлось набирать самому, а пришлось ограничиться людьми из одного перспективного, но неудавшегося проекта. Ребята молодые, бойкие, склонные к системному программированию. Так и слышно: сокеты, TCP/IP, Internet, паттерны Проходит месяц а, а прогресса никакого. Но каждое утро ребята бурно обсуждают Формула-1. Так и слышится А Шумахер то, а Алонсо то. После обсуждения формулы-1 переключались на алгоритм деления трафика интернета между сотрудниками. Да, был такой социалистический реликт справедливого дележа трафика между сотрудниками. Дело кончилось тем, что я предложил депозитникам и кредитникам уволиться. Что и произошло.
А тут начались новые времена. Фирмой владел и руководил приятный бизнесмен. Очень религиозный человек. И в фирме была толстая прослойка из его единоверцев. И все шло более-менее спокойно. А тут вдруг, я не знаю почему, появляется новый руководитель свежеиспеченный пенсионер КГБ высокого чина. Скоро мы получаем заказ на проектирование ERP для КГБ. С течением времени проект стал заваливаться и требовалось срочно укреплять группу разработки ERP. А мой проект был венчурным и работали в нем неплохие ребята. И вот начали выдергивать из моего проекта людей. И возразить нельзя: ведь мы сидим на шее других проектов. Так я вскоре опять остался один. А в фирме все росла прослойка КГБ. Начался проект по разработке аппаратуры шифрации-дешифрации.

Финал


В конце-концов, я остался один на проекте Аналитика. Подбросили сторонний заказ для управления МВД доработать ASP-проект. Доработал. И тут оказывается, что фирма банкротится. Это, кажется, был хитрый бизнес-ход: параллельно с процессом банкротизации возникла новая фирма с людьми из нашей банкротящейся фирмы и которые были целиком завязаны на КГБ- разработку криптографической аппаратуры. А старая фирма обанкротилась. И моя аналитика стала домашним проектом. Но по инерции интерес к проекту еще некоторое время не угасал. Пришла пора .Net. Я понял, что уже сравнительно легко перейти к SOA-архитектуре. Перевел почти всю бизнес-логику с Delphi на C#. Познакомился с WCF. Выделил сервисы. Определил интерфейсы. Реализовал шлюзы сервис-клиент. И вот она SOA-архитектура. Была задумка реализовать простую оркестровку сервисов, но, кажется, в этом уже нет необходимости. Эта функция стала системной.
Однажды звонит телефон. Звонили айтишники, которые задумали разработать бизнес-аналитику. Они обратились к владельцу портала tut.by у которого я когда-то разработал проект валютного ОДБ. Мой бывший шеф(царство ему небесное) всегда подходил ко мне на выставках и я ему рассказывал о своих успехах. Он высказал несколько дельных маркетинг-замечаний, которые заставили меня призадуматься. Так вот он направил ребят ко мне. Они рассказали о своих планах. Я им сказал, что их задумки уже давно реализованы, но положены на полку. И я им продемонстрировал проект. Они поняли, что это весьма трудоемкое дело и предложили выступить в роли толкателей моего проекта в банки. А я уже вступил в стадию пессимизма перспектив толкания в банки. Но ребята упросили меня попробовать. Я им дерзайте. Снабдил их рекламными материалами, письмом в банки и они пошли толкать. Результат оказался предсказуемым.
Я до сих пор не могу определить причины неуспеха.
Я попробовал отдать проект в EPAM. Там резонно ответили, что разрабатывают только под заказ, а венчурными разработками не занимаются. Есть у нас в Минске Парк Высоких Технологий ПВТ, работающий под покровительством президента республики. И в нем есть отделение Бизнес-инкубатор. Я послал туда предложение передать бесплатно им свой проект. Никакого ответа не последовало. Я посмотрел в интернете что такое инкубатор и нашел вот что. инкубатор (от лат. incubare, здесь высиживаю птенцов) аппарат для искусственного вывода молодняка сельскохозяйственной птицы из яиц. Он дает жирных, но неприспособленных для неинкубаторской, реальной жизни особей. Похоже на правду.

Описание проекта


Не все золото, что блестит
А теперь более детально о многострадальном проекте. Это чтобы было оценить обоснованы ли были мои ожидания и стоит ли о них переживать. Это не реклама проекта. Проект мертв. Я готов бесплатно отдать его в хорошие руки. Если кого-то заинтересуют некоторые детали проекта, то смотрите. Старый первоначальный вариант описания(поэтому возможно более интересный) вот здесь.

Принципы


  • SOA
    Под сервисом понимается автономное приложение коллективного пользования, функции которого предоставляются через анонсированный разработчиком API. Сервис можно размещать на любом компьютере сети. В архитектуре клиент-сервер сервис был один СУБД. В SOA сервисов может быть сколько угодно и размещаться они могут на разных компьютерах сети.
  • WCF связь клиент-сервис и сервис-сервис.
  • СУБД
    В БД никаких хранимых бизнес-процедур. СУБД достаточно загружена стандартными запросами сохранения, обновления и извлечения данных. Отсутствие хранимых бизнес-процедур сильно облегчает смену СУБД. Особенно если еще стараться ограничиваться стандартом SQL.
    А если обнаружится, что сервер БД слабо загружен, то на нем можно разместить сервис работы с показателями, например.
  • Отчеты
    В отчетах не должно быть никаких бизнес-функций. Отчет просто отображение группы показателей в заданную форму. А сами показатели должны рассчитываться в бизнес-слое сервисом машины показателей.
  • Интерфейсы
    Любое обращение к сервису должно быть только через интерфейсы.
  • Группы
    Однотипные объекты(показатели, субъекты, операции) могут объединяться по любому допустимому логическому критерию. Групп может быть сколько угодно.
  • Эксплореры
    Иерархические структуры должны отображаться в едином эксплорере


Основные функции


  • Ведение субъектов и их отношений. Поиск по отношениям. Ведение групп субъектов.
  • Ведение показателей и их динамических рядов. Ведение групп показателей. Значения показателей могут быть числовыми, текстовыми, логическими, календарными. Правило вычисления показателя любая композиция стандартных математических функций и агрегатных функций. Примеры агрегатных функций: максимум по субъектам, среднее по времени, минимум по времени. Значения показателя представляются в нескольких измерениях реальности: факт, план, прогноз индивидуальный, прогноз статистический, прогноз сценарный. Удивительно, но нигде в литературе я не нашел систематизированного перечня бизнес-показателей с их определениями, кодами, наименованиями и правилами вычисления.
  • Статистический анализ динамических рядов. Проверка статистических гипотез. Нахождение статистических параметров.
  • Регрессионный анализ. Нахождение наилучших регрессий.
  • Ведение портфеля. Получение платежного календаря.
  • Прогнозирование. Прогнозирование линейными трендами. Прогнозирование по портфелю фининструментов. Прогнозирование с учетом статистического отклонения прогноза от реальности.
  • Сценарное моделирование. Различные типы сценариев: операционный, портфельный, индикаторный.
  • Анализ. Различного рода анализаторы(декомпозиторы): разложение по показателям, по субъектам, по валюте, по исполнителям, по операциям.
  • Сравнения. Различного рода компараторы: сравнение по времени, по субъектам, по показателям.
  • Отображение в реальном времени. На каждого пользователя заводится табло своего типа, в котором отображается группа показателей.
  • Ведение плана счетов, иерархии объектов учета, иерархии бизнес-операций и их отображения на проводки.
  • Элементы бюджетирования: игра с распределением ресурсов.


Основные технологии


  • ETL. Это неунифицированный модуль перекачки данных от подсистем источников первичной информации. Основной источник бухгалтерский учет.
  • Эксплорер как универсальное отображение иерархических структур. Унифицированно отображаются иерархии показателей, субъектов, отчетов, запросов, объектов учета, операции.
  • Группы как наборы объектов, объединенные некоей общей внешней семантикой. Например, отчет группа показателей, отображаемая по заданной форме.
  • События. Монитор событий отслеживает рождение событий. Событие специфицируется логической функцией. Типы событий: внутреннее бизнес-событие, внешнее бизнес-событие, календарное событие. Монитор общий для всех сервисов. В каждом адресном пространстве работает свой оповещатель событий. Он извещается монитором событий. На события приложение подписывается.
  • Динамические формы. Пользователь может конструировать экранные формы таких типов: списочные, матричные(=табличные), иерархические.
  • Элементы объектооборота.
  • Сервисы.


Функциональные сервисы


  • Бизнес-ядро. По запросу клиента предоставляет ему для использования бизнес-объект и забирает объект от клиента. Кэширует объекты. Управляет связью между бизнес-уровнем и уровнем хранения данных.
  • Текущее состояние субъекта. Это набор показателей субъекта на текущую дату.
  • Симуляционное состояние. Это набор прогнозных показателей субъекта на заданную дату при заданном активном сценарии развития.
  • Статистика. Позволяет находить статистические зависимости.
  • Анализ показателей. Статистический и графический анализ реальных и виртуальных показателей.
  • Субъекты. Ведение субъектов и навигация по их множеству.
  • Отношения. Позволяет анализировать сколь угодно сложные цепочки отношений.
  • Бухгалтерские проводки. Подсказывает бухгалтерские проводки для заданной хозоперации.
  • Бизнес-табло реального времени. В заданном темпе отражаются текущие значения показателей. Отображение табличное и графическое.
  • Портфель финансовых инструментов. Ведение фининструментов, навигация по их множеству, отработка сценария пассивной эволюции, определение платежного календаря.
  • Бюджетирование, точечное или распределенное во времени.


Технологические сервисы


  • Идентификация и аутентификация. Для новых бизнес-объектов генерятся идентификаторы. При вхождении пользователя в приложение проверяется его пароль в приложении.
  • Доступ. Реализовано два типа доступа: по разрешению, и по запрещению. Уровни доступа: тип, метод типа, экземпляр.
  • Машина показателей. Вычисляет значения производных показателей и сохраняет эти значения в БД. Показатели загружаются из БД.
  • Монитор событий. Отслеживается сформированный пользователем набор событий. О наступившем событии сообщается оповещателю, находящемуся в адресном пространстве приложения
  • Оповещатель. Приложение оповещается о наступившем событии. Оповещатель генерирует идентичное событие. На событие клиент подписывается сам или его подписывает технолог.
  • Объектооборот. Бизнес-объекты прогоняются по технологическому конвейеру.
  • OLAP. Особенность: базисом для OLAP-кубов служит не столько сырые данные OLTP-систем, сколько слой рассчитанных показателей над OLTP-системами. Это делает OLAP-разработки простыми и более производительными, чем непосредственно на оперативных данных. Размерность пространства измерений можно увеличить, подцепляя к показателю, соответствующий субъект и делая его характеристики размерностями куба.


Объекты


Все объекты делятся на:
  • D-объекты. Это голые данные без бизнес-функций.
  • B-объекты. Это бизнес-объекты, содержащие D-объекты и бизнес-функции.
  • P-объекты. Это объекты представления, содержащие D-объекты с атрибутами их отображения.
  • C-объекты. Это коммуникационные объекты, служащие для передачи D-объектов между разными адресными пространствами.
  • DB-объекты. Это объекты для отображения D-объектов на базу данных и получения D-объектов из базы данных.


Взаимодействие объектов:

image


D-объект объект данных


Предназначен для хранения данных. D-объект это B-объект без бизнес-функций. Объект данных содержит только данные и не содержит бизнес функции. Имя: <имя>D. Пример: HomoD.
Все объекты данных образуют D-дерево. Корень TopD
D-объекты содержат не бизнес-методы:
  • CopyTo
  • CopyFrom
  • Clone
  • GenId
  • GenParentId
  • ToString


Об идентификации
TypeId идентификатор типа. В таблице Tip каждому типу соответствует запись с Id=TypeId. В пределах типа может быть сколько угодно экземпляров. Их различают атрибутом Code.
Code идентификатор экземпляра в пределах типа. Значит, пара TypeId и Code дают идентификатор экземпляра. Однако разные поставщики данных могут поставлять однотипные экземпляры. Например, платежных поручений может быть сколь угодно. Чтобы провести идентификацию на этот уровень задействуем ещё экземплярный уточнитель IQ, который уникален в пределах всех экземпляров на все время жизни решения. Тогда тройка TypeId, Code, IQ и есть идентификатор в поле Tip. Можно было обойтись одним IQ, но это неудобно для ручной работы с БД.

B-объект бизнес-объект


Это все сущности, являющиеся элементами прикладной области, которая представляется как взаимодействие бизнес-объектов. Предназначен для хранения бизнес функций. Пример бизнес-объектов: человек, счет, платеж. Пример не бизнес-объектов: все виджеты(=контролы).
Бизнес-объект содержит объект-данные и бизнес функции. Имя: <имя>. Пример: Homo
Каноническое соответствие: <имя>D <--> <имя>. Каждый B-объект имеет методы:
  • Сохранить
  • Извлечь
  • Удалить


Все бизнес-объекты образуют иерархию. Корень TopB

C-объект коммуникационный объект


Предназначен для передачи данных. Он содержит данные в в форматек, пригодном для передачи данных между разными адресными пространствами. Имя: <имя>С. Пример: HomoC
Каноническое соответствие: <имя>С <--> <имя>D.
Все коммуникационные объекты образуют иерархию. Корень TopC
Методы C-объекта:
  • CopyToD. Копировать себя в D-объект
  • CopyFromD. Копировать на себя из D-объекта


P-объект представляемый объект


Предназначен для отображения данных на визуальные формы. Содержит объект данных и параметры визуального отображения.
Имя: <тип объекта>P. Пример: HomoP
Все объекты представления образуют иерархию. Корень TopP. Каноническое соответствие: <имя>D <--> <имя>P. Многие P-объекты совпадают с D-объектами, так как не нуждаются в параметрах визуализации.

F-объект форма


Служат для визуального представления объектов данных.
Имя: <тип объекта>F. Пример: HomoF
Все формы образуют иерархию. Корень TopF. Каноническое соответствие: <имя>F <--> <имя>P.
Все функциональные формы наследуются от TopF. Основные свойства и методы:
Каждая форма имеет методы:
  • Получить объект
  • Отобразить объект на поля формы
  • Сформировать объект из данных формы
  • Сохранить объект
  • Удалить объект

С каждой формой соотносится свой контекст выполнения UserContext, прописанный в TopF.
Все grid-таблицы на формах могут выдаваться в Exсel. Этот метод реализован в TopF. В графе Exсel можно вводить любой код показателя или допустимое правило вычисления.
Тракт обработки: вводимые атрибуты на форме --> экземпляр D-объекта --> экземпляр B-объекта --> бизнес-функция --> экземпляр D-объекта --> экземпляр DB-объекта --> кортежи таблиц в БД.
Тракт отображения: кортежи таблиц в БД --> экземпляр DB-объекта --> экземпляр D-объекта --> экземпляр P-объекта --> отображаемые атрибуты объекта на форме.
Единообразность поведения форм обеспечивается общим корнем форм. Альтернативный метод использование интерфейсов. Достаточно реализовать в компоненте интерфейс, а вызывающей программе проверить его наличие. Такая реализация предотвращает перегруженность корневой формы.

DB-объект объект базы данных


Предназначен для общения с БД: сохранение объекта данных в БД и извлечение из БД объекта данных.
Имя: <имя>DB. Пример: HomoDB
Каноническое соответствие: <имя>.D<><имя>.DB.
Все DB-объекты образуют иерархию. Корень TopDB
Все бизнес-объекты регистрируются в таблице Tip с уникальным Id. Специфика объекта отображается в специфичных таблицах.

Архитектурная схема


image



Уровень данных


Он имеет дело только с D-объектами. Они образуют D-дерево. Вершина D-дерева объект TopD. Назначение объекта TopD обеспечить одинаковое поведение всех D-объектов.

Уровень хранимых данных


Он имеет дело только с D-объектами и DB-объектами. DB-объекты образуют DB-дерево.
Функции:
  • Извлечение из внешней памяти объектов данных
  • Сохранение во внешней памяти объектов данных
  • Кэширование объектов данных

Посредством DB-объекта D-Объект может отображаться в несколько кортежей и в несколько таблиц БД.
В БД нет никакой бизнес-логики. СУБД хватает забот по SQL-запросам. При желании можно разместить бизнес-сервис на сервере СУБД. При желании можно разместить все на одном компьютере.
Для доступа к БД используется ADO.Net. Уровень имеет дело с двумя потоками данных:
От БД к уровню логики. Уровень данных извлекает из БД нужные данные и формирует из них бизнес-данные, которые на уровне бизнес-логики войдут в бизнес-объект.
От бизнес-уровня к БД. Уровень данных получает бизнес-данные от уровня бизнес-логики и кладет их в БД.
Есть возможность кэширования данных. Кэширование сохранение объекта в оперативной памяти, если объект часто используется. Так в банковских расчетах постоянно нужен корреспондентский счет. Скэшировав его, не нужно будет часто обращаться к БД он будет браться из кэша.
DB-объект имеет функции:
  • Взять данные из бизнес-объекта
  • Передать данные в бизнес-объект
  • Сохранить данные в БД
  • Извлечь данные из БД
  • Обновить данные в БД
  • Удалить данные из БД

Правильно отрабатывать многообъектную транзакцию(не делать самому Commit и RollBack)
Один из параметров вызова DB-объекта DB-connection

Каждому типу объектов сопоставлена таблица в БД с именем типа объекта. Все объекты имеют уникальный Id и представлены в таблице Tip. В этой таблице есть атрибуты, являющиеся общими для всех объектов:
  • Id
  • PId
  • TypeId
  • Code
  • Name
  • CreatedOn
  • Description
  • StateCode
  • Author

Все объекты в этой таблице образуют иерархию, которая есть иерархия типов. Это значит, что каждый тип представлен записью, а все экземпляры типа подчинены этой записи(PId экземапляра = Id типа).
Для типа его Id это TypeId; Code есть идентификатор в пределах типа.

Детали объектов представлены в таблицах, соответствующих типу. Например, атрибуты объекта Homo представлены в таблице Homo.
Все атрибуты типа содержатся в сцепке таблицы Tip и таблицы, соответствующей типу. Соответствующее представление именуется как <тип>_v. Например, Homo_V.

Вершина DB-дерева объект TopDB. Назначение объекта TopDB обеспечить одинаковое поведение всех DB-объектов.

Бизнес-уровень


Он имеет дело только с B-объектами. B-объекты образуют B-дерево.
Функции:
  • Реализация бизнес-функций
  • Предоставление бизнес-интерфейсов
  • Предоставление бизнес-служб(приложение коллективного пользования):
  • WCF-службы
  • Web-службы

Вершина B-дерева TopB. Назначение объекта TopB обеспечить одинаковое поведение всех B-объектов.

Уровень представления


Он имеет дело только с P-объектами и F-объектами.
Функции:
  • Запрос данных к бизнес-уровню и получение от него объектов данных
  • Отображение данных в формы и отчеты
  • Формирование объектов данных и передача их на бизнес-уровень

В форме визуально отображается во время выполнения экземпляр объекта. Вызов и завершение каждой функции пользовательского объекта вызывает отметку этого события в регистрационном журнале .Log. Вся бизнес-логика должна находиться в методах бизнес-объектов. В форме эти методы должны вызываться, но сама форма не должна вычислять, например, проценты по кредиту, срок погашения и т.д. На форме не должно быть никакой бизнес-логики, а только логика интерфейса пользователя. К логике интерфейса пользователя относятся:
  • Управление видимостью интерфейсных элементов
  • Управление группами связанных кнопок
  • Тип шрифта
  • Цвет и т.д.


F-объекты образуют F-дерево. Вершина TopF.
Назначение объекта TopF обеспечить одинаковое поведение всех F-объектов.

Обязательные принципы


Минимизация энтропии


Всякий разработанный проект подчиняется некоей термодинамике: любой проект обладает энтропией. Возрастание энтропии есть стремление к разрушению стройности структуры(=порядок), стремление к беспорядку. Стремление к минимальной энтропия требует единообразия. Пусть даже безобразно, но единообразно. Всякое разнообразие должно быть осознанным и преследовать явную функциональную цель, а не эстетики, оригинальности и т.д. Никакого необоснованного разнообразия это лишняя энтропия. Борьба с энтропией самое главное. У некоторых программеров уже один модуль содержит тьму энтропии. Примеры необоснованного разнообразия:
  • Разные имена одной сущности в разных модулях
  • Разная дисциплина компоновки кода
  • Разные рисунки для кнопок одинакового назначения
  • Разные подсказки для кнопок одинакового назначения
  • Разный стиль программирования. Так иногда цикл по списку начинают с 0 до Сount-1, а в другом месте с 1 до Count.
  • Разный стиль именования
  • Разный стиль комментариев иногда до кода {а сейчас будет представлен }, а иногда после кода {это был описан }


Приоритет глобальных целей над локальными


Под локальным уровнем понимается уровень модуля, а не приложения или уровень приложения, а не группы однородных приложений. Так стремление к локальной оптимизации может привести к глобальной неоптимальности, стремление к локальной изящности к глобальной неуклюжести. Пример 1: стремление уйти от глобальных переменных может утяжелить систему, требуя создать заново объект, который мог быть передан через глобальную переменную. Пример 2: при создании новой формы, может показаться, что ее не нужно наследовать от базовой формы. Поначалу все Ok и экономятся ресурсы. Но потом от формы может потребоваться выполнение общей функции форм, которая уже реализована на уровне общей формы, но ее нет в частной форме. Значит, форму нужно будет доделывать, дублируя то, что уже сделано в общей форме.
Адекватность(неизбыточность, но полнота) отображения(Принцип минимальной избыточности). Любое отображение должно быть настроено на контекст учитывать все уже заданные параметры. Так если клиент является физлицом, то в эксплорере нужно отображать только счета физлиц; Если речь идет о кредитах, то в эксплорере счетов должны отображаться только ссудные счета. Это относится не только к ouput- элементам интeрфейса, но и к input-элементам: комбобоксам, листбоксам поставщикам данных.

Ковариантность при смене базового субъекта.


Сейчас многие Query содержат начальные значения параметров привязанные к текущему базовому субъекту. Это удобно для просмотра в DesignTime, но это может привести к непереносимости проекта. Чтобы этого не случилось, нужно в RunTime всегда устанавливать значение параметра запроса.

Никакого видимого мусора


Мусор то, что не используется. Неиспользуемые элементы интерфейса должны быть невидимыми.

Слоение


Функций отображения не должно быть в бизнес-объекте.
Реализация бизнес- класса не должна использовать объекты и методы уровня представления.
Функций связи с БД не должно быть в бизнес-объекте
Реализация бизнес-класса не должна использовать объекты и методы уровня хранения.

Слабая внешняя связность


Условие слабой связности класса(внешняя связность) мера использования в классе других классов этой же предметной области. Желательно иметь слабо связанные классы. Это свойство называется изолированностью.Объект не должен в своих методах использовать как параметр объект класса, расположенного в дереве ниже по уровню или использующего объект как элемент агрегации. Пусть B наследник A и в A есть метод A.Do(prA:B). Тогда его нужно убрать из A в B: B.Do(prA:A).

Сильная внутренняя связность


Условие сильной сцепленности класса(внутренняя связность) класс должен содержать прикладные методы, объединенные семантикой. Так присутствие в бизнес-объекте методов отображения нарушает этот принцип. Сбоку припёку не должно быть. Класс- не безыдейный конгломерат, а монолитное образование, подчинённое общей бизнес-цели. То, что может рассыпаться, должно быть разъединено. Слабая внутренняя связность должна привести к распаду бизнес-объекта на несколько других объектов.
Один класс один модуль
Общее правило: один класс один модуль. Во всяком случае, в одном модуле могут быть только сильно связанные объекты

Связь с БД


За связь с БД отвечают специальные объекты брокер БД.

Связь Форма-объект


image


Каждой форме сопоставляется рабочий объект. Создает рабочий объект только терминальная форма. Объект может передаваться форме извне. Форма может передавать его другой форме. Каждая форма имеет методы ShowOnObject, GetObjectFromForm. Это виртуальные методы.

Локальность


Если форма вызывается из модуля, то она, как объект, должна быть локальной. Это предотвратит возможную коллизию параллельного использования одной формы.

Исключения


Все прерывания фиксируются в регистрационном журнале и передаются клиенту.

Кодификация


Все кодификации, которые потенциально изменяемы реализуются как кодификаторы структуры {код, имя}. Постоянные кодификации(дни недели, например) реализуются как перечислимые типы.

Реализация

Отображение дерева объектов в информационную базу
В таблице Tip прописываются все объекты одинаковым образом независимо от типа. В таблице Movement отображается движение объекта (смена состояний и выполнение методов) одинаковым для всех объектов образом.
Объекту TopB сопоставляется таблица Tip(Top обычно зарезервированное слово в СУБД, поэтому имя Top таблицы оказалась неудобным), а каждому конкретному бизнес-классу сопоставляется конкретная таблица в БД: объект Homo<>таблица Homo и т.д.
Отношения между субъектами фиксируются в таблице Relation.
При создании объектов, входящих в иерархию наследования должно соблюдаться вот что: не может быть терминальной записи без головной. Это нужно иметь в виду при ручном формировании базы импорте таблицы Банки, например. Чтобы добавить сущность Банк, нужно чтобы была сущность Предприятие. Чтобы добавить сущность Предприятие, нужно чтобы была сущность Субъект. Чтобы добавить сущность Субъект, нужно чтобы была сущность TopD.
На общем(независящем от типа) уровне реализованы эксплорер объектов, операция, продвижка объектов. Эксплорер объектов работает одинаково для всех типов объектов. На конкретном уровне работают формы специфичные для каждого объекта.

Эксплорер объектов


Это формы, позволяющие навигацию по дереву типов объектов с показом списка конкретных объектов, принадлежащих активному узлу дерева типов.
Панель Состояние предоставляет возможность дополнительной фильтрации по состояниям объектов.

Двигатели состояний


Это формы, позволяющие продвинуть состояние

Операции


Работа с операцией унифицирована формой fOperation.
Из этой формы можно выйти на спецификацию объектов операции и на платеж операции. Пример выхода на платеж по кнопке Специфицировать платеж операции:

Эксплорер операций


Аналогичен эксплореру объектов.
Конкретную операцию можно выдернуть из эксплорера и посмотреть по кнопке Индивидуализировать.

Доступ


Управление доступом к бизнес-объектам делается на бизнес-уровне. Доступ может быть по разрешению или по запрещению. Доступ может быть:
  • К типам бизнес-объектов (Запрещен или разрешен доступ ко всем экземплярам указываемого типа и всем методам объекта этого типа)
  • К методам типа (Запрещен или разрешен доступ к указанным методам всех экземпляров данного типа)
  • К экземплярам (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и всем методам объекта этого типа)
  • К методам экземпляров (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и специфицируемым методам объекта этого типа)
  • К формам


Структура решения


Решение есть совокупность проектов(терминология Visual Studio). В решении около 200 проектов. Все проекты кучкуются так:
  • Data-проекты. Каждому D-типу соответствует D-модуль.
  • Business-проекты. Каждому B-типу соответствует B-модуль.
  • Communication-проекты. Каждому C-типу соответствует C-модуль.
  • Presentation-проекты. Каждому P-типу соответствует Р-модуль.
  • Interface-проекты. Модули содержат описания интерфейсов.
  • Technology-проекты. Содержат утилиты.
  • Infra-проекты. Содержат инфраструктуру решения.
  • Resource-проекты. Содержат ресурсы проектов.
  • Service-проекты. Реализуются сервисы.
  • Gate-проекты. Выполняют роль шлюза между сервисом и приложениями. В одноадресном варианте шлюз не нужен.
  • Application-проекты. Содержат конкретные приложения.
  • Test-проекты.
  • Delivery-проекты.
  • Site-проекты.
  • Addin-проекты.

Отображение структуры решения в каталог ОС: каталог ОС решения повторяет структуру решения.

Структура приложения



image


Старт-программа


Головная программа аутентифицирует пользователя. В головном модуле создаются все интерфейсы. Т.е. головная программа склеивает реализацию и объявление интерфейсов. Создаётся диспетчер приложения. Интерфейсы передаются диспетчеру приложения. Диспетчер создаёт формы и передаёт им соответствующие интерфейсы.

Реализация распределенной обработки


WCF-сервис


Некоторые наборы функций можно реализовать как сервисы приложения коллективного пользования с четким API. В итоге получается приложение, работающее в нескольких адресных пространства. Эти пространства могут размещаться на любых компьютерах сети. Связь между пространствами реализуют модули-шлюзы. Они размещаются в клиентском приложении.
Задачи шлюза:
  • Обработка трафика от сервиса к клиенту:
  • Принять С-объект по API с сервисом
  • Преобразовать С-объект в D-объект
  • Передать D-объект клиенту
  • Обработка трафика от клиента к сервису:
  • Принять D-объект от клиента
  • Преобразовать D-объект в C-объект
  • Передать C-объект сервису по API c сервисом

Задача сервиса:
  • Обработка трафика от клиента
  • Принять C-объект
  • Преобразовать его в D-объект
  • Передать D-объект функциональной части по локальному API
  • Обработка трафика к клиенту
  • Принять D-объект от функциональной части по локальному API
  • Преобразовать его в С-объект
  • Передать клиенту C-объект


Web-службы


Все как и для WCF с заменой WCF-сервиса на WEB-сервис. Последний есть клиент над WCF-сервисом, с тем, чтобы остальные WCF-клиенты не замечали WEB-сервис.

Специфика


Объекты учета


Счета бухгалтерского учета основной источник аналитики. Основной объект аналитики показатель. В его описание входит код объекта учета, которому соответствует показатель. Поэтому чрезвычайно важно хорошо построить множество кодов объектов учета.
Объекты учета образуют дерево объектов учета. Его ведение доступно пользователю.

Дерево типов


Все типы решения образуют дерево. Это дерево отображается в таблицу Tip. Id записи TypeId типа. Все объекты представлены в Tip записями, подчинёнными записи типа объекта. Например, записи объекта Homo подчинены записи типа Homo записи с Id=Homo.TypeId. Такое решение позволяет создать универсальный эксплорер объектов, отображающий иерархию типов.

Движение


Движение экземпляра объекта есть смена состояний. Движения всех объектов определяются одинаково объектом Movement и хранятся в таблице Movement.

Отношения


Явные отношения те, которые поддерживаются информационной моделью. Например, отношение подчинения между субъектами.
Все неявные отношения между объектами фиксируются в таблице Relation при установлении отношения. При заключении кредитного договора должно фиксироваться отношение кредитования. При появлении изменений к плану счетов между документом План счетов и изменениями к нему устанавливается отношение Изменение. Оно явно не присутствует в модели. Выделение каждого отношения в явное отношение перегрузит модель.
Отношение можно специфицировать, вызвав форму Отношение.

Транзакции и целостность


Все экземпляры любых объектов(в том числе и субъектов) имеют уникальный идентификатор. Сфера действия уникальности БД на все времена работы проекта.
Все экземпляры сценариев имеют уникальный идентификатор идентификатор сценария. Сценарий последовательность воображаемых операций. Все экземпляры любых операции имеют уникальный идентификатор идентификатор транзакции. Сфера действия уникальности все таблицы на все времена работы решения. Операция может породить другие операции, которые без первичной, начальной операции не имеют смысла. Если отменяется начальная операция, то отменяются все порожденные операции. Такая цепочка операций рассматривается как одна транзакция и все операции цепочки получают одинаковый идентификатор транзакции. Пример цепочки: Открытие счета Заключение договора на открытие счета Оплата открытия счета. Этой цепочкой связываются три объекта: счет, договор, платеж. Отмена открытия счета отменяет и договор и платеж.
Каждая операция оформляется как часть транзакции. Каждая операция начинается и заканчивается регистрацией в журнале регистрации.
Объект может иметь связанные, присоединенные к нему объекты в списке CoObjects. Эта связка хранится в БД.

Базовый субъект


Это субъект, который является владельцем эксплуатируемой системы.
Если в двустороннем отношении или функции неясно с кого начинать, то начинать нужно с базового субъекта. Примеры:
  • Операция Купить. Покупает базовый субъект, а продает его контрагент.
  • Операция Продать. Продает базовый субъект, а покупает его контрагент.
  • Отношение Договор. Первая сторона, субъект это базовый субъект. Вторая сторона договора, контрагент это контрагент базового субъекта.


Доступ и регистрация


Любая функция начинает с отметки в журнале регистраций и завершает отметкой в журнале регистраций.
Доступ дифференцируется так:
  • Доступ к типам
  • Доступ к методам типа
  • Доступ к экземплярам типа

Условие доступа может интерпретироваться двояко:
  • На разрешение (что не разрешено, то запрещено). Пример: Id=1 доступ только к объекту с Id=1
  • На запрещение(что не запрещено, то разрешено). Пример: Id=1 доступ только к объекту с sysId<>1


Хотелось бы


  • Применить машинное обучение. Например, определение кредитоспособности клиента, определение степени надежности бизнеса. Но где взять достаточно большой массив реальных примеров для обучения?
  • Заложить в базу знаний, помимо правил вычисления показателей, какие-нибудь экономические теории микроэкономики. Это, конечно, динамические теории. Т.е. это что-то типа:


Так в чем же причина облома?


Попытаюсь классифицировать возможные причины неудачи:
  • Это идея-фикс? Это не мне судить.
  • Невостребованность?
  • В невостребованность не верю. Востребованность почти очевидна. Не будем же мы дискутировать о невостребованности давления, пульса, РОЕ в медицине. Например, в последнее время на слуху ССП- сбалансированная система показателей. А это подмножество аналитики.
  • Отсталость по сравнению с аналогичными проектами?
  • Плохая архитектура?
  • Инструментарий?
  • Сверхученость?
  • Маркетинг?
  • За спиной не стояла крупная фирма, имеющая историческую репутацию?


Я склоняюсь к совокупности последних трех причин.
И последнее, чтобы не посчитать статью за рекламу проекта, я готов бесплатно отдать весь проект в хорошие руки. Это около 20 Мб исходников. Конечно, там будет над чем и посмеяться: это был мой первый проект на C#. Многими из современных свойств C# там и не пахнет. В первую очередь, я бы изменил событийный подход первых выпусков C# на современный, более высокоуровневый подход к событиям. Во-вторых, можно было подумать о возможности асинхронной обработки.
Заканчивая и, думая нажать ли кнопку Опубликовать, начинаю терзаться смутными сомнениями А кому это нужно? И что тебе надобно, старичина? А потом решил не отвечать на этот вопрос

Всем желаю никогда не встречаться с обломом любимых проектов. Успехов!
Подробнее..
Категории: Анализ и проектирование систем , Развитие стартапа , Моделирование , Архитектура , Показатель , Бизнес-аналитика , Прогнозирование , Сценарий

Должен ли системный аналитик вторгаться на чужую территорию?

20.04.2021 16:13:49 | Автор: admin

На Хабре много статей о том, кто такой системный аналитик.С базовым определением профессии все понятно. Но я хочу поговорить о разграничении полномочий в командах с разным набором ролей. В зависимости от ситуации границы обязанностей системного аналитика размываются, требуя дополнительных знаний. Хочу поделиться своими наблюдениями о том, какие из этих знаний делают аналитика более востребованным на рынке труда.

Конкретные обязанности и рабочие процессы, в которых участвует системный аналитик, существенно зависят от внутреннего устройства компании. В качестве точки отсчета предлагаю взять мою текущую роль в команде.

В Maxilect системный аналитик в первую очередь концентрируется на технических задачах. Он немного понимает программный код, может самостоятельно писать базовые SQL запросы, осознает и применяет различные принципы построения архитектуры приложений, а также их взаимодействия. Умеет работать и проектировать веб сервисы и очереди (MQ). Но бизнес анализом ему заниматься не приходится.

Команда получает от бизнеса задачи, которые отвечают на вопрос: Что нужно сделать. А системный аналитик решает Как команда это реализует. Детально прорабатывая задачу, системный аналитик может обсудить промежуточный вариант с разработчиком или обсудить что-то с архитектором. Но именно он решает, какие веб-сервисы будем вызывать, как обрабатывать полученные данные и какие для этого нужны доработки. Организует обсуждение со сторонними командами, если требуется. Фактически, здесь роль системного аналитика близка к канонической.

Но Maxilect - далеко не первое место моей работы. За весь свой трудовой путь я видела разные реализации этой роли. Видела компании, которые в целях экономии пытаются повесить функцию системного анализа на разработчиков. Но лично я придерживаюсь принципа, что каждый должен заниматься своим делом. Разработчику лучше сосредоточиться на коде, в то время как понимание требований обеспечит аналитик.

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

Дисклаймер о джунах, мидлах и сениорах

Конечно, масштабы воздействия на проект зависят от уровня подготовки самого аналитика. Джуну с его базовым пониманием теории сбора требований и бизнес-процессов вряд ли кто-то доверит в одиночку закрыть две-три роли. Ему бы погрузиться в принципы работы системы, да инструменты освоить от Word до UML или какого-нибудь Balsamiq.

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

Не исключено, что именно совмещение и дает этот толчок в развитии. Но разделение на уровни настолько условно, что дальше я не буду акцентировать внимание на том, как смежные роли с ним связаны.

Поговорим о том, какие направления аналитику открываются чаще.

Аналитик и бизнес

По моим наблюдениям чаще всего системному аналитику приходится закрывать функции бизнес-аналитика.

И системный, и бизнес аналитик - это звенья цепочки между заказчиком и разработчиком. Первый - немного в сторону технической части, второй - в сторону бизнеса. Грань между ними очень тонкая, поэтому роли часто путают. А в небольших проектах эти роли обычно закрывает один человек. Если мы не говорим о масштабном проекте, то одной головы вполне достаточно, чтобы разобраться в бизнес-процессах и держать в уме архитектуру системы - знать, что где лежит и какие именно нужно внести изменения, чтобы реализовать новые требования.

Я обратила внимание, что из этих двух ролей в вакансиях компании чаще пишут системный аналитик, предлагая совмещения в текстовом описании позиции или между строк. Мне кажется, бизнес-аналитик - это более редкий узкий специалист, которого не каждая компания может и хочет себе позволить. Так что, закрывая обе роли, ты становишься более универсальным специалистом, которому легче найти работу.

Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. It - сфера динамично развивается и в ней появляются новые смежные профессии. Еще 3-4 года не многие слышали про роль product owner, а сейчас роль владельца продукта все более востребована. И я уже ни раз сталкивалась с командами, где именно PO определяет, какие бизнес-задачи войдут в скоуп спринта, а какие нет. В каком-то смысле, помимо выполнения своих основных функций, product owner встраивается в цепочку разработки вместо бизнес-аналитика, взаимодействуя и с заказчиком, и с системным аналитиком.

Нужно ли тестировать?

Системный аналитик должен хорошо разбираться в системе и ее функциях. Поскольку он ориентируется в требованиях заказчика, я все чаще вижу, что аналитиков подключают к тестированию. Я и сама на текущем проекте тестирую отдельные модули системы. Тестировщики же фокусируются на более объемных частях задачи.

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

Системный аналитик vs архитектор

Системный аналитик не является архитектором, но часто ему приходится закрывать эту роль хотя бы частично, хотя на мой взгляд это неправильно.

Архитектор - важный и нужный специалист, но обычно его ищут на большие проекты, где недостатки архитектуры могут в буквальном смысле похоронить хорошее решение. Если архитектор на проекте присутствует, системному аналитику приходится тесно с ним взаимодействовать, особенно в период онбординга.

Когда проект обходится без архитектора, его функции делятся между другими участниками команды, например техлидом, product owner, а иногда и самим системным аналитиком (такую схему работы на троих я встречала на одном из бывших проектов). Это нельзя назвать обычной или правильной практикой. Но так или иначе системному аналитику все равно придется разбираться в архитектуре, понимать, какая технология и за что отвечает.

Необходимость изучить архитектуру проекта тянет за собой много требований. Надо уметь работать с интеграционными сервисами - понимать, что куда передать, чтобы совместить две системы, что такое интеграционная шина и как она работает. Надо понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди (RabbitMQ, Kafka). Необходима работа с базами данных.

Системному аналитику не обязательно уметь проектировать все это, но надо следить за технологиями, понимать, зачем и в каких ситуациях они применяются.

Выйдет ли из аналитика лид?

Стоит следить и за трендами в управлении. Аналитиков часто ставят на роль лидов - дескать, они хорошо понимают в проекте, умеют общаться с бизнесом. На мой взгляд, это не всегда оправданный шаг. Руководство - это в большей степени менеджерская работа, которая отнимает много времени. Это в первую очередь распределение задач, полученных сверху, между мидлами и джунами в своей команде. Мне кажется, эту работу проще возложить на руководителя проекта или product owner - мне так работать привычнее. А сильный аналитик может сосредоточиться непосредственно на своей работе. Но для некоторых переход из системного аналитика в лиды - это хороший шаг в карьере, к которому лучше готовиться заранее, изучая особенности работы команд, различия в подходах к разработке (это уже про Agile, Scrum, Kanban).

Вместо заключения отмечу, что роль системного аналитика для проекта крайне важна. Но для нее нельзя написать список необходимых и достаточных навыков. В этой сфере знания никогда не бывают лишними. Может пригодиться и опыт кодинга, и умение писать запросы в БД, и общие представления о сфере, в которой разрабатывается проект. Все это делает системного аналитика более востребованным на рынке труда.

Автор статьи: Лейла Кадырова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Подробнее..
Категории: Анализ и проектирование систем , Управление персоналом , Лайфхаки для гиков , Карьера в it-индустрии , Бизнес-аналитика , Блог компании maxilect , Системный аналитик , Бизнес-аналитик

Нужна ли сертификация для бизнес-аналитика?

01.05.2021 18:10:38 | Автор: admin

Наверное, каждый системный или бизнес-аналитик на каком-то этапе карьеры задумывается о том, что было бы неплохо получить профессиональный сертификат. В этой статье я попробую ответить на вопрос - а нужно ли и зачем?

Что вообще за сертификация?

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

В основном эти сертификаты позиционируются для специалистов в бизнес-анализе, но у нас они также рассматриваются как подтверждение уровня для системных аналитиков, аналитиков требований, software analyst и т.д. Тут есть огромное поле для дискуссий, но я не про это.

Зачем это нужно?

Думаю, что каждый аналитик, покопавшись в предмете, сможет найти для себя ответ на этот вопрос. Я же рассмотрел три, наиболее часто упоминаемые причины в принципе, для любой сертификации:

  • сертифицированные специалисты зарабатывают больше;

  • подготовка к сертификации помогает упорядочить свои знания и позволяет выявить пробелы\гэпы в профессии;

  • сертификация - это такой способ самому себе доказать, что ты крут )

Давайте разберемся подробнее. Я запустил опрос в сообществах и чатах аналитиков и собрал около 4х десятков ответов о том, что думают по этому поводу сами аналитики.

Результаты опроса среди аналитиковРезультаты опроса среди аналитиков

Большая часть аналитиков не считает, что сертификация не приводит к более высокой зарплате. А что думают работодатели?

В других сферах IT в требованиях к кандидатам частенько мелькают названия сертификатов в той или иной технологии и, подозреваю, что сертификация до сих пор приносит хорошие дивиденды обладателям этих документов. Что не так с аналитиками? Может быть это у нас только так?
Давайте посмотрим вакансии в России и за ее пределами.

2% в лучшем случае! Только 2% работодателей хотя бы просто упоминают в своих вакансиях названия сертификатов или организаций.

Не буду вдаваться в подробности расчетов. Просто поясню, что я отбирал вакансии Бизнес-аналитик\Business analyst на соответствующем ресурсе, перебирал все варианты названий сертификатов и в зачет брал лучший результат. Так, например, в Германии неожиданно, самым популярным оказался IREB. В итог вошли не все ресурсы, на которых я искал, потому что где-то было совсем пусто, где-то под фильтр явно попадало что-то не то. Но, думаю, вывод напрашивается такой - сертификаты аналитиков для работодателей не важны!

Но если сертификаты не нужны, кто вообще их получает?

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

Но экзамены - дело не дешевое. Готовы ли аналитики сами оплачивать экзамены?

Из ответивших на опрос аналитиков сертификаты оказались всего у 4 респондентов, у 3 из них - сертификаты IIBA.

Интересно, что здесь заявленная готовность платить за сертификацию самостоятельно не подтвердилась. Но, думаю, это можно списать на недостаточность выборки.

Мнение экспертов

Никита Харичкин, преподаватель курса Системный аналитик, руководитель отдела системной аналитики в СБЕРе

Рекомендуете ли Вы аналитикам сертифицироваться и почему?

Я рекомендую прохождение сертификации. Но перед этим специалисту стоит оценить свои возможности и саму необходимость сдачи экзамена на стандарт в текущем периоде карьеры. Потому что важно четко понимать свои ожидания от сертификации: подходит ли именно этот сертификат, какую пользу он принесет в работе как самому специалисту, так и работодателю. Кроме этого, стоит проверить, нет ли более простого и быстрого способа получить ожидаемую пользу, и оценить, получится ли выделить время на подготовку к сертификации, если она все-таки нужна.

Сертификация полезна для закрепления знаний и улучшения качества своих артефактов в реальной работе. Кроме этого, опора на теорию помогает направить дискуссию в конструктивное русло, будь то выступление на конференции или планерка внутри команды. Еще одним не очевидным плюсом сертификации является выделение темных и светлых областей в собственных компетенциях. То есть стандарт помогает понять, в чем специалист уже преуспел, а что нужно улучшить, какие темы совершенно в новинку. Он может составить индивидуальный план развития в соответствии со стандартом, продемонстрировать руководителю свои сильные стороны и понять, какие новые навыки нужно освоить, чтобы запросить соответствующие задачи.

Но не стоит рассматривать сертификацию как инструмент для повышения заработной платы на текущем месте работы. Однако специалист может договориться с руководителем об оплате или выделении рабочих часов на подготовку к сдаче экзамена. С точки зрения руководителя наличие сертификата не будет решающим, но точно выделит сотрудника среди сотни других.

На каком этапе карьеры аналитика Вы бы рекомендовали задумываться о сертификации, если, конечно, рекомендуете?

Сертификацию не следует проходить до приобретения 2-3 лет опыта по специальности. Для стартовых позиций и младших специалистов гораздо важнее осваивать новое, углубляться в предметные области, все гипотезы проверять на практике и учиться на своих и чужих ошибках. В течение этого периода за знаниями и экспертизой лучше обращаться к руководителю или наставнику. Он даст конкретную обратную связь с деталями по контексту. И это будет намного полезнее для специалиста и проекта, чем получение общих теоретических знаний. А спустя 3+ года работы можно задуматься, стоит ли на данном этапе подтверждать свои компетенции.

К выбору сертификата, при этом, необходимо подходить с умом. Не стоит брать экзамены начального уровня, если вы уже переросли его. Равно как и браться за серьезный сертификат, будучи младшим специалистом. Каждый сертификат декларирует требуемый уровень подготовки и количество часов опыта. Поэтому стоит отталкиваться от этого если перерывов в карьере не было, то 1 год включает примерно 1700 часов.

Какие способы подготовки к экзаменам Вы могли бы порекомендовать?

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

В подготовке также помогает комьюнити единомышленников, которые тоже начали готовиться к выбранному вами сертификату. Если рядом никого нет, то создайте это движение сами внутри компании или региона. Живое обсуждение и сторонние мнения благоприятно повлияют и на мотивацию, и на конечный результат.

Денис Гобов Senior Business Analyst, DataArt; Основатель тренинговой компании по бизнес-анализу; Вице-президент по профессиональному развитию, Украинское отделение IIBA

Рекомендуете ли Вы аналитикам сертифицироваться и почему?

Рекомендую. Но при этом основную практическую пользу вы получите именно от процесса подготовки. Возьмем три момента времени: начало подготовки, день до экзамена, день после экзамена. Разница между первой и второй значительная, если вы серьезно подошли к вопросу. А между 2 и 3 минимальная. Сертификат хороший стимул довести дело до конца.

Что дает сертификация:

структуризацию знаний и целостную картину деятельности;

наличие сертификата от серьезной международной организации выделяет вас на фоне других сотрудников/кандидатов на рынке труда;

повышает ЧСВ/снижает неуверенность в вашем профессионализме (пресловутый эффект самозванца).

Регулярные опросы, проводимые IIBA, свидетельствуют, что сертифицированные аналитики получают в среднем больше чем несертифицированные. Но я к этому утверждению отношусь с некоторым скепсисом. Эта зависимость может работать и в другую сторону: лучше зарабатывающие бизнес-аналитики не прочь потратить деньги на сертификацию.

На каком этапе карьеры аналитика Вы бы рекомендовали задумываться о сертификации, если, конечно, рекомендуете?

Для серьезных сертификаций, например, CBAP/CCBA от IIBA или PMI-PBA от PMI, требуется наличие опыта работы. Поэтому я рекомендовал смотреть в сторону сертификаций, как только вы наработаете опыт и решите его структурировать. Другими словами, 2 года опыта и можно начинать смотреть в сторону сертификаций.

Какие способы подготовки к экзаменам Вы могли бы порекомендовать?

Если тезисно:

прочитать свод знаний от организации, сертификат которой хотите получить, несколько раз;

применять теорию на практике;

трнироваться отвечать на вопросы, похожие на экзаменационные (лучше выбирать проверенных временем провайдеров баз вопросов);

пройти обучение на курсах (проверьте, что они построены на нужном вам своде знаний, тренер тоже сертифицирован, а выпускники успешно сертифицируются);

почитать, что рекомендуют коллеги, уже прошедшие сертификацию.

Дарья Таткова, преподаватель курса Системный аналитик, системный аналитик в сфере финтех. В настоящий момент главный аналитик в СБЕРе.

Рекомендуете ли Вы аналитикам сертифицироваться и почему?

Сертификация системных аналитиков не так распространена, как сертификация других IT-специалистов (например, программистов). К счастью, в последние годы стали появляться квалификационные институты, подтверждающие навыки и в сфере аналитики. И это безусловный плюс, потому что в первую очередь среди специалистов увеличивается общая грамотность, что позволяет структурировать знания и требования к работе.

Сертифицироваться нужно не столько ради самой корочки, сколько ради обучения. Вдумчивая подготовка к экзаменам позволяет заполнить существующие пробелы в собственных знаниях, дает возможность почувствовать себя увереннее и в целом расширяет профессиональный кругозор.

На каком этапе карьеры аналитика Вы бы рекомендовали задумываться о сертификации, если, конечно, рекомендуете?

К выбору сертификата я бы подходила после нескольких лет опыта по направлению будучи не ниже middle-специалиста. В начале работы, когда нет четкого понимая вектора движения карьеры, сделать правильный выбор сертификата сложно.

Какие способы подготовки к экзаменам Вы могли бы порекомендовать?

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

Денис Бесков, руководитель компании по подготовке системных аналитиков, поделился своим мнением по этому вопросу в презентации по этой ссылке.

Спасибо всем, кто согласился ответить на вопросы!

P.S.: Сори, что пришлось порезать ссылки на ваши курсы. Хабр счел это за рекламу.

Мнение автора

Какие я сделал выводы по итогам этого небольшого исследования. Сертификация вряд ли даст вам возможность получить более высокооплачиваемую работу. Но я также считаю (хотя мне нечем это подкрепить), что получение сертификата может быть хорошим аргументом, чтобы обосновать повышение зарплаты, если в вашей компании не предусмотрено регулярных процедур с оценкой вашей работы или грейдов с внятно описанными требованиями. Мне сложно представить руководителя, который скажет, что "это вы для себя рожали".

Думаю, что подготовка к сертификации имеет смысл, если вы хотите развиваться в этой области дальше. Если же вы видите свой дальнейший путь в другой области: в роли архитектора, владельца продукта или менеджера\лида, то, вероятно, вам будет полезнее потратить время на развитие навыков и компетенций, востребованных в этой области.

Всем удачи на проектах! Занимайтесь тем, что вам интересно и повышайте свою квалификацию!

Подробнее..
Категории: Анализ и проектирование систем , Сертификация , Бизнес-аналитика

Матрица рисков компании. Алгебраическое исследование

17.12.2020 18:19:07 | Автор: admin


Мне доводилось принимать участие в упражнениях с Матрицей рисков компании.
Действие происходило в три этапа. Первый: мальчики и девочки анкетировали вопросами типа перестал ли ты пить коньяк по утрам, на которые надо отвечать только да или нет.
На втором этапе показывалась научно-обоснованная матрица рисков.
На перманентном третьем этапе все подразделения той компании пытались из года в год сдвинуться на более низкие позиции на матрице, но это удавалось только за счет личного обаяния. Те же, кто не смог сдвинуться становились крайними по любой неудаче бизнеса.

Инстаграм

Вот типовая Матрица рисков, которую предлагает Гугл.



Для примера в Интернете найдена случайная Матрица рисков из очень старого отчета.



Числа внутри цветных прямоугольников означают содержательную интерпретацию риска, которая пока не очень нужна. Описание риска очень широко и размыто. Не верится, что все компоненты описания по отдельности и вместе дают единственное число в очень узком диапазоне.

Если следовать типовой матрицы Гугл, то всем содержательным описаниям вероятность и влияние можно поставить в соответствие конкретные числа.

Вот модернизированная матрица исходной.



Она не очень удобна для работы, так как симметрична относительно дополнительной, а не главной диагонали.

Возможно, что Матрица рисков в такой форме более удобна для менеджеров. Её перестройка с симметрией относительно главной диагонали не меняет сути матрицы. Кроме того, всегда можно сделать шаг назад и вернуться к исходному представлению.
Перестроение матрицы происходит путём замены порядка строк на обратный (симметрия относительно вертикальной центральной оси). В результате получена матрица симметричную относительно главной диагонали.



Эти же преобразования для исследуемой Матрицы рисков.



Числа, отличные от 0 это номер риска, связанный в итоге с неким структурным подразделением. Эта кодировка имеет место только в связи с бюрократической иерархией в компании, а не с рисками. Например, для элемента {1,5}. В плане риска ситуация ничем не будет отличаться, если совместить описания риска1 и риска5. Если это разные риски, то можно уменьшить шаг матрицы и поместить риск в более подходящую позицию.
В итоге преобразования должны приводить к тому, что каждый различный риск является отдельным элементом.

Позиция [1,3] в стандартной системе нумерации матриц означает элемент, находящийся на пересечении 1-ой строки и 3-го столбца. Для рассматриваемой матрицы в позиции [1,3] стоит число 2. Это означает, что если имеет место шкала с максимальным значением 5 почти произошло (1.), то в [1,3] ожидаем 3 среднее (0.6) влияние. Пусть влиянию в таргитируемом промежутке соответствует определенный ущерб (damage): 5-d5, 4-d4, 3-d3, 2-d2,1-d1. Тогда, если за определенный период имело место 1 происшествие из группы 2, то ущерб составит 1.*0.6*d3*1, а если за этот же период произошло n происшествий из группы 2, то ущерб составит 1.*0.6*d3*n

Тогда исследуемая матрица примет вид.



Проводится еще одно преобразование: транспонирование путём перемены мест столбцов и строк.



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

Без легенды матрица будет выглядеть так.



Первая основная задача.



Получив матрицу А можно приступать к решению первой основной задачи: при известном количестве и качестве произошедших событий вычислить размер ущерба.

Пусть за определенный период произошло 2 очень сильных событий, 3 критичных, 1 среднее, 5 минимальных и 7 незначительных. Умножив матрицу А на вектор количества событий получаем структуру ущерба.



Общий ущерб.



Теперь можно проверять точность оценок, вносить коррективы, оценивать возможные варианты сокращения размера ущерба.

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

Алгебро-философский рубеж.



Для каждой квадратной матрицы имеется однозначное линейное преобразование, соответствующее этой матрице. Обозревая матрицу сложно понять какое линейное преобразование стоит за ней. Кроме того, неизвестно в каком базисе произведено матричное представление.

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

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

Рассматриваемая Матрица рисков имеет две нулевых строки и один нулевой столбец. В любом случае определитель этой матрицы будет равняться нулю. Ниже приведен рисунок, показывающий как компания намерена снижать риски.



Стрелками показано как будут снижаться риски. Каким образом не важно, важно, что при этом новая ситуация опять представляется матрицей. Этой матрице соответствует некое линейное преобразование. Плюс переход от старой матрицы к новой это матрица и линейное преобразование.

Что означает ненулевой определитель? Это возможность шагать вперед-назад. Если определитель нулевой, то шага назад сделать нельзя.
При этом матрица снижения рисков изначально связана со старой матрицей. То есть на картинке можно и нужно парить вперед-назад, а в формализованном варианте шагать вперед-назад нельзя.

Следующая проблема связана с тем, что большой риск с малой вероятностью может быть сопоставим с риском от очень большого количества малых рисков с малой вероятностью.
В приведенном выше примере 7 незначительных событий формально не вызывают никакого ущерба. Понятно, что это не так. Отсутствие малых рисков только подчеркивают недостаточную некорректность формирования Матрицы рисков.

Пусть определитель Матрицы рисков не равен нулю и это следствие преемственности работ по снижению рисков, а не искусственное для бизнеса требование метода.

Итак, имеются: Матрица рисков, которая соответствует неизвестному линейному преобразованию и неизвестному базису; определитель Матрицы, который не равен нулю.

Что можно сделать? Привести Матрицу рисков к каноническому виду с понятным ортонормированным базисом.

В работе Александра Емелина дается следующее аллегорическое описание преимуществ канонического вида. Предположим, что есть листок бумаги, на котором написано некоторое слово. Но он сложен так, что слова не видно. После канонического преобразования листок разворачивается таким образом, что слово можно увидеть. Если используется ортонормированный базис, то листок бумаги останется того же размера.

Вторая основная задача. Каноническое представление.



В рассматриваемую матрицу добавляются элементы так, чтобы определитель не равнялся нулю. Чтобы избежать слишком больших формул значения округляются.



Далее по стандартной схеме матрица приводится к каноническому виду.

Собственные значения Матрицы рисков.



Дальнейшая работа с символическими значениями будет тяжёлой при ортогонализации и результат будет невозможно визуализировать (очень громоздкие символические матрицы).
Пусть (для примера) d1=1, d2=2, d3=5, d4=8, d5=12.
Тогда Матрица рисков М принимает вид.



Проверяется, что определитель М не равен нулю.
Вычисляются собственные значения.



Находится матрицу из собственных векторов.



Она ортогонализируется. Получается матрица ORT ортонормированных векторов.



Для проверки первый вектор (столбец) умножается попарно на все остальные.



В новом базисе находится представление исходного линейного преобразования (определяющего Матрицу рисков) в переменных z1, z2, z3, z4, z5.



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



Причем коэффициенты при квадратах соответствуют ранее вычисленным собственным значением.

Новый вид Матрицы рисков в ортонормированном базисе.



Практическая польза канонического представления.



Что можно сказать про исходную Матрицу рисков?
Она представляет неизвестное линейное преобразование.
Её строки обозначаются (сверху-вниз) как x1, x2, x3, x4, x5. Строки Матрицы рисков представляют разложение по неизвестному базису.
Так
x1=10*d5*b1+0*b2+0*b3+0*b4+0*b5,
x2= 8*d4*b1+0*b2+4*d4*b3+0*b4+0*b5, и так далее.

Наличие ортонормированного базиса обеспечивает свободу хождения между переменными X и Z.
В переменных Z явно видна функция линейного преобразования, которая в исходной Матрице рисков была непонятной.

Явная польза от канонического вида состоит в возможности корректировки типа угроз. Если изначально классификация шла по шагу в 20%, то теперь ее можно пересмотреть пересчитав значения концов диапазонов в новом базисе. Останется также 5 типов событий, но шаги между ними будут разными.

Фактически новая форма позволяет Матрице рисков уйти от роли жупела и стать нормальным инструментом цифрового управления бизнесом. Одним из многих.
Подробнее..
Категории: Математика , Оптимизация , Бизнес-модели , Бизнес-аналитика , Риски , Матрица риска , Бизнес риски

Специфические задачи Data Science в Банке

28.02.2021 18:05:07 | Автор: admin
image

В течение последних пяти лет я проработал в Центральном Аппарате Сбербанка в Управлении Валидации моделей машинного обучения (machine learning, ML) и видел много узких мест, которые возникают при разработке и валидации моделей машинного обучения.

В этой статье сначала предполагал рассмотреть основные информационные системы некоторого абстрактного Банка X, поскольку именно на базе уже сложившихся информационных систем строится работа дата-аналитиков, а также обучаются и работают ML-алгоритмы принятия решений. Но, когда начал писать, вдруг обнаружил, что на самом деле намного интереснее обсудить ряд тем и подзадач, которые всплывают при построении и валидации самых базовых моделей Банка, то есть моделей кредитного риска.



Риск-менеджмент и расчет кредитного риска можно считать прародителями data science в Банке, так как управление кредитным риском является исконно банковской прерогативой. Именно умелое управление рисками позволяет банкам предложить что-то ценное рынку кредитно-финансовых отношений. Представление о том, что банк просто кладет себе в карман процентную маржу между процентом по кредиту и процентом по вкладу в корне не верно, хотя мне иногда приходится такое слышать от людей незнакомых с внутренней кухней банковского бизнеса.

Банк с одной стороны берет на себя все риски невозврата кредита, а с другой стороны дает гарантии вкладчику о возврате вложенных средств. Альтернатива вкладу в Банке, одолжить свои деньги напрямую заемщику без гарантий возврата. Банк же в свою очередь способен давать гарантии, так как с одной стороны обладает подушкой безопасности в виде основного капитала и изначально закладывает потери от невозврата кредитов в свои финансовые показатели (формирует резервы). С другой стороны Банк умеет просчитывать вероятность того, что выданный им кредит заемщик не вернет. Конечно же никто не может предсказать в точности, вернет ли долг конкретное физическое лицо или компания, но в среднем по большому числу заемщиков вероятность оценить можно.

Банк будет финансово устойчивым только в том случае, если та прибыль, которую он зарабатывает на процентной марже покроет убытки от невозврата кредитов и прочие сопутствующие расходы Банка.

Устоявшаяся банковская практика



Перед тем, как перейти к обсуждению прогнозных моделей и непосредственно задач data science, буквально на минуту остановимся на специфике того, как банк работает с клиентом. Банк, и особенно крупный банк, это хорошо организованная система, в которой прописывается буквально каждый шаг. Это касается и взаимодействия с заемщиками.

В частности в отношении заемщиков часто применяется такое понятие, как дефолт. Дефолт это статус, который присваивается клиенту в том случае, когда появляется почти полная уверенность, что клиент деньги банку уже не вернет, по крайней мере в полном объеме. О правилах и процедурах, по которым клиентам присваивается статус дефолта договариваются на уровне специально созданной для этого рабочей группы. А затем вышеоговоренные правила прописывают во внутренней нормативной документации.

Если клиенту присвоен статус дефолта, обычно говорят, что клиент вышел в дефолт. С точки зрения процессов Банка это означает, что будут запущены определенные процедуры взаимодействия с клиентом. Возможно будет решаться вопрос о банкротстве заемщика, Банк попытается реализовать заложенное имущество, взыскать денежные средства с поручителей или продать долг должника коллекторам и т.д.

Так уж исторически сложилось, что ожидаемые потери от невозврата кредитов принято раскладывать на три компоненты:

EL = PD*EAD*LGD

где EL expected loss, ожидаемые потери;
PD probability at default, вероятность того, что заемщику будет присвоен статус дефолта в течение следующего года, начиная с даты оценки;
EAD exposure at default, все те денежные средства, которые клиент на дату выхода в дефолт должен вернуть Банку, включая как выданную денежную сумму, так и проценты, штрафы и комиссии;
LGD loss given default, доля от общей задолженности заемщика перед банком, которую Банк себе уже не вернет. То есть это чистая потеря для Банка;

Если я где-то отхожу от учебных определений и понятий, то заранее прошу прощения, поскольку основная моя цель это не написать правильный пересказ учебников, а ухватить суть существующих проблем. Для это приходится порой рассуждать на пальцах.

Попробуем теперь сформулировать типовую задачу для дата-сайентиста. Первое, что стоит уметь прогнозировать это вероятность дефолта PD. Здесь все кажется просто. У нас задача бинарной классификации. Дайте же нам данные с истинной меткой класса и всеми факторами и мы быстро соберем скрипт с двойной кросс-валидацией и подбором всех гиперпараметров, выберем модель с лучшей метрикой Джини и все будет в порядке. Но почему-то в реальности так не получается.

Нет никакой истинной метки класса


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

Мы плохо знаем своего клиента


С накоплением истории выданных кредитов появляется желание построить более сложные модели, а для этого нужны дополнительные сведения о клиентах. Тут-то и выясняется, что раньше нам эти сведения были не нужны, и соответственно их никто и не собирал. Как результат в собранных выборках много пропусков, что сводит на нет саму идею построить более информированную модель. И, если бы только это.

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

Регулятор требует делать модели интерпретируемыми


Говоря регулятор, я имею в виду Центробанк, который требует делать модели понятными. Должен быть понятен не только сам прогноз, но и правила, по которым этот прогноз был сделан. Справедливости ради, скажу, что в большей мере такое правило касается только так называемых регуляторных моделей. Регулятор в целях обеспечения устойчивости банковской системы в целом постоянно мониторит деятельность банков по ряду ключевых показателей, среди которых, например, находится расчет достаточности капитала на покрытие непредвиденных потерь во время возможных экономических и финансовых кризисов.
Что означает требование к интерпретируемости? А означает оно, что в большинстве случаев придется довольствоваться моделями в виде логистической регрессии или дерева решений. Про нейронные сети, ансамбли, стекинги и прочие современные архитекторы придется забыть.

Прокрустово ложе устоявшейся банковской практики


Отраслевой стандарт де-факто требует оценивать ожидаемые потери как произведение трех величин: PD, EAD и LGD. Это справедливо только в том случае, когда события развиваются по одному и тому же сценарию. Клиент либо возвращает кредит, либо нет. В первом случае, считается что никаких потерь нет. Во втором же случае, предполагается наличие некоторой суммы под риском (EAD).

На практике, платежное поведение клиентов не сводится к двум простым вариантам, а граница между этими вариантами весьма условна. Заемщик может выйти в дефолт и через месяц, и через год, и через два, а затем после того, как ему присвоят статус дефолт, вдруг вернуться к платежам и выплатить весь кредит. Более того, отклонения от графика платежей могут быть и по суммам и по срокам, с опережением или наоборот отставанием от графика. Финансовый результат для Банка во всех случаях будет разный.

Я не говорю, что нельзя свести все разнообразие вариантов поведения заемщика к схеме расчета трех компонент в принципе. Конечно же все зависит от задачи. Где мы потом хотим эту модель применить? Если для оценки кредитного риска по пулам (группам) заемщиков, то все возможные отклонения учитываются различными калибровками и расчетом средневзвешенных значений. Но, если наша цель заключается в персонализации подхода при выдаче кредита, в том числе в персональном подборе предложений, важным становится прогноз потока платежей со стороны клиента или прогноз чистой приведенной стоимости.

На чем спотыкаются продвинутые data-driven альтернативы



Надо понимать, что вся отраслевая банковская практика была сформирована в те годы, когда не было никакой Big Data или машинного обучения, а все вычисления сводились к построению скоринговых карт. Брали все существенные факторы, влияющие на кредитоспособность заемщика, и оценивали в виде баллов, далее эти баллы суммировали и по сумме баллов определяли выдавать или не выдавать кредит.

С накоплением истории выданных кредитов и развитием вычислительной техники процедуры принятия решений в Банке постепенно усложнялись. Скоркарты превратились в модели логистической регрессии, которые строятся скриптами на python. Клиентов и продукты Банка начали сегментировать для того, чтобы внутри каждого сегмента строить свои узкозаточенные модели. С другой стороны с ростом объемов хранилищ данных появилась возможность собирать и вместе хранить все больше и больше информации во взаимосвязанном виде.

В конечном итоге все движется к идее, когда для каждого пришедшего клиента будет почти мгновенно обнаруживаться наилучшее предложение (оптимальный банковский продукт), которое бы максимизировало CLTV (customer lifetime value) на заданном временном горизонте, либо иную метрику в зависимости от текущего состояния Банка и целей его стейкхолдеров.

Почему бы для решения вышеописанной задачи не применить мощную нейросеть (то есть пресловутый искусственный интеллект)? Перечислю несколько мешающих этому обстоятельств:
Центробанк требует, чтобы модели участвующие в расчете достаточности капитала применялись в живом кредитном процессе. То есть именно эти модели должны применяться в принятии решений о выдаче кредитов, быть интерпретируемыми и проходить ряд обязательных валидационных тестов;
базы клиентских данных постоянно расширяются и дополняются. Например, относительно новыми видами данных является биометрия, веб-аналитика, аналитика мобильных приложений, скоринг социальных сетей. Добавление новых атрибутов происходит в динамике, а соответственно исторических данных по ним у нас практически нет;
продукты и процессы Банка постоянно видоизменяются и требуется перерасчет CLTV по клиентам и расчет NPV (net present value) по новым продуктам. А для того, чтобы построить модель приемлемого качества надо подождать несколько лет, накопить исторические данные и вычислить фактические значения CLTV или NPV на выборке из реальных заемщиков;

Итог:


При всем желании нельзя рассматривать построение прогнозных моделей в Банке как чисто математическую задачу. На практике решаются бизнес-задачи, которые ко всему прочему сильно переплетены с требованиями регулятора в лице Центробанка.

Порой кажется, что в банковскую область могут проникнуть компании извне с сильным data science и поменять правила игры. Но для того, чтобы выдавать кредиты, надо играть по общим правилам, а следовательно становится Банком со всеми вытекающими последствиями.

Появление нового крутого финтех-стартапа в кредитовании, по-видимому, в большей степени завязано на поиск лазеек в правовом поле, чем на внедрение инноваций в машинном обучении.
Подробнее..
Категории: Искусственный интеллект , Машинное обучение , Machine learning , Data science , Data mining , Аналитика , Финансы в it , Data engineering , Бизнес-аналитика , Банк

Робопрактика для аналитиков в red_mad_robot

29.04.2021 10:23:13 | Автор: admin

Привет! Мы открываем летнюю робопрактику для начинающих аналитиков. Познакомим с процессом разработки диджитал-продуктов в red_mad_robot, основными артефактами, особенностями работы с внешними клиентами и внутренней кухней компании. Стартуем в конце мая, лучших пригласим к себе в команду.

Что планируем

Встречу-знакомство проведём 25 мая в нашем офисе, остальные лекции и практики пройдут онлайн. В робопрактике примут участие 5 опытных железных аналитиков и 15 практикантов.

Робопрактика предполагает неполную занятость: два раза в неделю вторник и четверг, по два часа: с 19:00 до 21:00 по МСК. Между лекциями будут небольшие домашки, а в конце курса лекций проверочная работа. Практиковаться закончим 2 июля.

Кого ждём

Начинающих аналитиков из Москвы с опытом работы системным или бизнес-аналитиком от года до полутора лет. Важно, чтобы ты понимал процессы разработки ПО, имел представление о работе дизайнера, программиста и тестировщика. А если у тебя есть профильное образование в сфере бизнес-аналитики, то это железный плюс!

Программа робопрактики

Производство и аналитика

  1. Что такое производство.

  2. Роль аналитика в производстве.

  3. Виды аналитиков.

  4. Особенности оплаты работ на проекте.

  5. Типы проектов и работ.

  6. Этапы и команда.

  7. Спринты.

Работы на старте проекта

  1. Технический брифинг клиента.

  2. Бизнес-брифинг клиента.

  3. Какие артефакты создаются на старте проекта.

  4. Правила коммуникации с клиентами.

Архитектура

  1. Что такое архитектура.

  2. Из чего состоит архитектура.

  3. Источники данных для построения архитектуры.

  4. Технические особенности платформ (Web, iOS, Android и кроссплатформа).

  5. Что такое HLD и из чего состоит.

  6. Кто работает с HLD.

Проектирование

  1. Интервьюирование команды клиента.

  2. Взаимодействие с командой разработки.

  3. Артефакты в процессе проектирования и на выходе.

Выявление, сбор и формализация требований

  1. Виды требований и источники их появления.

  2. Подходы к описанию требований (формализация).

  3. Критерии качества требований.

Клиент-серверное взаимодействие

  1. Основы клиент-серверного взаимодействия.

  2. Веб-сервисы: REST, SOAP, GraphQL.

  3. Что такое API.

  4. Спецификация API.

Основные мероприятия проекта

  1. Грумминг и планирование спринта.

  2. Демо для клиента.

  3. Завершение спринта/проекта.

Как попасть на робопрактику

Чтобы отправить заявку на участие, заполни Google-форму. Заявки принимаем до 14 мая. Результаты прохождения тестовых заданий вышлем в ответном письме.

Если не успел подать заявку не расстраивайся. Аналитиков с опытом мы приглашаем на собеседование, а начинающих ребят пригласим практиковаться в следующий раз. Если есть вопросы, пиши на school@redmadrobot.com.

Подробнее..
Категории: Аналитика , Бизнес-аналитика , Блог компании red_mad_robot

Внедрение сквозной бизнес-аналитики

11.02.2021 16:05:53 | Автор: admin

Цифровизация бизнеса

Сегодня даже малый бизнес имеет возможность быстро запустить рекламу для любого сегмента аудитории, настроить несколько рекламных каналов иоценить их реальную эффективность впродажах продукта.

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

Сосквозной аналитикой повышается эффективность digital-рекламы. Компании, которые отслеживают всё ипринимают решения наоснове данных выигрывают конкурентную гонку. Поэтому можно сказать что сквозная аналитика жизненно необходима.

Компании тратят деньги нарекламу, привлекают клиентов, получают прибыль спродаж своих товаров иуслуг. Логично будет применить кинтернет-маркетингу показатель возврата инвестиций ROI, аточнее, ROMI.

Return on Marketing Investment или сокращенноROMI это показатель рентабельности рекламных кампаний и в целом инвестиций в маркетинговую деятельность. Рентабельность оперирует такими метриками, как окупаемость, прибыль, возврат вложений.

Посчитать ROMI нетак просто, как кажется. Посмотрим напростом примере.

  • Отчётность компании ООО Ромашка заянварь 2019года:

  • Затраты нарекламу: 120000рублей

  • Продажи 700000рублей

  • Маржинальный доход (без рекламных вложений) 210000рублей

ROMI равен75%. Коэффициент выше 0, т.е. вроде бы всё хорошо. Новсёли правильно мы посчитали?

Расчет ROMIРасчет ROMI

Представим, что застройщик построил новый ЖК, создал для него сайт изапустил рекламную кампанию. Вот статистика запервые полгода:

Статистика продажСтатистика продаж

Впервые 3месяца продаж нет. Если считать ROMI помесяцам, кажется, что реклама неработает. Нопотом появляются первые продажи. Делаем вывод, что люди, пришедшие порекламе впервые месяцы, покупают несразу. Соответственно, если построить управленческий отчёт за определённыйпериод, указывая все затраты ивсе продажи, он будет некорректным сточки зрения возврата инвестиций врекламу. Только вбизнесах смоментальным спросом такой отчёт будет приближённо отражать реальную ситуацию.

Сквозной принцип в аналитике

При использовании обычной управленческой отчётности, в которой зафиксированы расходы на рекламу и продажи за тот или иной период, более-менее корректно ROMI посчитать можно только при определенных условиях:

  • Моментальный цикл сделки

  • Отсутствие органического (не рекламного) трафика

В остальных случаях подсчёт будет некорректен. И главное, с такими данными мы можем посчитать только общий ROMI, но мы не узнаем ROMI отдельных рекламных каналов. Причина проста: мы знаем, сколько денег потратили на каждый рекламный канал, но не знаем, с каких именно пришли клиенты.

В связи с этим, необходимо отслеживать каждую заявку и заказ, сохраняя информацию о рекламном источнике. В этом и смысл сквозной аналитики. Без этого анализировать более чем 1 рекламный канал с не моментальными продажами не получится никак.

Логическая ошибка высокого ROMI

Основная логическая ошибка, которую сознательно, либо неосознанно, допускают многие маркетологи, это стремление к высокому ROMI. Кажется, что чем выше возврат инвестиций, тем лучше. Так ли это?

С одной стороны да, высокий ROMI является прекрасным достижением.

С другой, следует учитывать 2 вещи:

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

  • Сам по себе высокий ROMI это не конечная цель, а лишь промежуточная. Поэтому кейсы маркетологов, где они гордятся высокими показателями ROMI, вызывают вопросы, если не описано, что дальше с этим делать.

Как считать? Пример:

  • Средний чек: 10 000

  • Маржинальность:30% (3000)

  • Конверсия (впродажу): 2,00%

  • 100 кликов мы можем получать по 10 рублей за клик

Расчет ROMIРасчет ROMI

Зеленым выделены лучше показатели, рыжим худшие.

Как видим, при небольшом количестве трафика у нас максимальный ROMI, но минимальная выручка. Далее, при увеличении бюджета ROMI падает, стоимость привлечений 1 клиента растёт. До какого-то момента растёт общая прибыль, потом она начинает также падать. И наоборот, при большом трафике максимизируется ROMI уменьшается и становится отрицательным.

Зато валовая прибыль растёт имаксимизируется лишь при ROI ~200%. Если же учитывать повторные заказы (LTV), картина меняется. Допустим, число повторных заказов равное 50% от числа новых заказов. Тогда прибыль максимизируется при ROI равном ~140%. Если же повторных заказов больше, выгодней удерживать еще меньший ROI.

Аесли повторных заказов больше? Тогда вполне возможно, что ROI ниже 100% даст максимальную долгосрочную прибыль. Понятно, что вреальных условиях даже максимизация прибыли невсегда является приоритетом: часто бывают риски, проблемы роста имногое другое. Ноона явно намного важнее, чем максимизация ROI, которая является ложной целью.

Сквозная аналитика как жизненная необходимость

Неболее 30% клиентов делают заказ при первомже посещении сайта. Конкретное количество зависит оттеплоты рынка ицикла принятия сделки, которая обычно невелика. Прежде чем что-то купить (совершить конверсию), человек, привлечённый разными рекламными источниками, заходит насайт несколько раз. Мультиканальные конверсии появились вGoogle Analytics несколько лет назад, номногие досих пор используют принцип LastClickWins, т.е. считают конверсии попоследнему заходу.

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

Аналитика по каналамАналитика по каналам

Проблема1:

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

Проблема2:

Покупатель совершает не1покупку. Повторные покупки могут быть намного больше, чем размер первого заказа. Значит, нужно считать LTV, а для этого не обойтись без внедрения CRM.

Проблема3:

Каналы общения. Нужно отслеживать все каналы. В противном случае мы получим аналитику, не точно отражающую реальность, с необоснованными выводами, писанными вилами по воде.

Нельзя при этом считать заявки только через сайт или даже заявки + звонки. Вот поэтому необходимо выстраивать сквозную аналитику.

Сквозная аналитика в маркетинге метод анализа эффективности маркетинговых инвестиций (ROMI) на основе данных, отслеживающих полный путь клиента, начиная от просмотра рекламного объявления, посещения сайта и заканчивая продажей и повторными заказами (LTV).

Для реальной оценки эффективности маркетинга стоит поставить конкретную задачу:

  • Определить KPI для оценки;

  • Определиться с тем, какими должны быть дашборды, отчеты;

  • Выяснить, кто отвечает за проведение оценки эффективности РК в организации;

  • Проанализировать пути пользователей;

  • Учесть данные как онлайн, так и офлайн, убедиться в их качестве;

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

Обычно для сквозной аналитики требуется объединить информацию изрекламных каналов (например, Google Ads, Яндекс.Директ, Facebook), каналов коммуникации (телефонный звонок, онлайн-заказ через корзину насайте, электронная почта идр.) иCRM-системы, где находится информация опродажах (Wikipedia).

Аналитика трафикаАналитика трафика

Ни показы, ни клики, ни даже звонки нескажут ничего. Мы точно знаем, сколько затратили нарекламу, инам нужно также точно знать, сколько мы сэтого заработали. Ксчастью, сейчас это стало реальностью.

Кому нужна сквозная аналитика

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

  1. Компания должна продавать товары или услуги в онлайн. Например, к ритейлу она мало применима, а к ecommerce более чем.

  2. Чтобы внедрение было целесообразно экономически, рекламный бюджет рекомендуется не менее 1-2 тысяч $ в месяц.

  3. Чем больше рекламных каналов, тем выше эффективность аналитики. Сравнение внутри 1 канала тоже полезно, но на 3-5 каналах эффективность наверняка будет выше. Вы сможете сравнивать и каналы друг с другом и кампании, запросы, настройки внутри каналов.

  4. У вас есть повторные продажи и есть % отвала (т.е. конверсия лидов в продажу далека от 100%). Иначе можно обойтись просто веб-аналитикой.

Кому необходима сквозная аналитикаКому необходима сквозная аналитика

Кому не обязательна сквозная аналитика

Компании с очень длительным циклом сделки. Они будут ждать, пока система аналитики начнет приносить реальную пользу, потратив заэто время существенную сумму насам сервис.

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

Компаниям сLTV меньше нескольких средних чеков: отчет обисточниках первой покупки дает представление обэффективности канала вцелом.

Проблемы внедрения сквозной аналитики

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

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

  • Разделение на каналы возможно только в расходах, но не в доходах. Это хорошо, когда рекламный канал один.

  • Без связки рекламного источника с продажей, при долгом цикле сделки даже интуитивного понимания, какая реклама сработала и сработала ли вообще, например, реклама запущена зимой, а заявки и продажи начались летом. Без сквозной аналитики мы не узнаем, были ли эти клиенты прогреты рекламой с самого начала или же они обратились по другим источникам.

Внедрение сквозной аналитики позволяет понимать, какие рекламные каналы, кампании и ключевые слова участвовали в привлечении клиента. Такая детализация позволяет эффективно управлять рекламными кампаниями и экономить существенный % рекламного бюджета. Система Roistat заявляет об экономии до 56%, но даже более пессимистичные 30% при бюджете в 200. тыс в месяц составляют сумму ощутимые 60 тыс. рублей.

Проблема 1: отдел продаж

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

Т.е. без грамотного построения отдела продаж небудет сквозной аналитики. При этом нужно, чтобы отдел продаж использовал вработе CRM-систему. Всего лишь!

Проблема втом, что CRM сама посебе отделу продаж ненужна отслова совсем. Чтобы она стала ему нужна иневоспринималась вштыки, нужно соблюдение множества условий:

Для менеджера:

  • Система должна сразу облегчать какие-то привычные действия, которые раньше делались менее удобно;

  • Она недолжна дублировать другие системы идействия только замещатьих;

  • Обращения всех клиентов должны попадать всистему автоматически;

  • Общение склиентами (отправка писем, звонки ит.д.) проходит внутри системы.

Для руководителя (РОП`а):

  • Прозрачная информация покаждому менеджеру иего действиям;

  • Настройки распределения лидов взависимости отэффективности работы сотрудников;

  • Гибкая система выстраивания KPI менеджеров иотчётности.

Проблема 2: техническая

Популярные облачные сервисы (в том числе системы сквозной аналитики) обычно интегрируются друг с другом в пару кликов. Однако в реальности всё не так просто, как кажется. Рассмотрим некоторые проблемы, которые могут возникнуть:

Для облачных систем аналитики.

  • Ограниченная функциональность. Вы не можете настроить всё так, как нужно именно вам. С некоторыми системами нет стандартной интеграции, и приходится интегрироваться при помощи API и вебхуков.

  • Облачная система аналитики обычно является для вас закрытым чёрным ящиком. Вы не знаете, что и как она считает, и приходится просто верить. Точность подсчёта может вызывать много вопросов: данные в системе аналитики часто не совпадают с данными CRM, а сделки не идентифицируются с источником.

  • Работая с облачной системой аналитики, вы доверяете свои данные третьей стороне. В крупных компаниях отдел маркетинга может просто не получить разрешения от службы безопасности на подобные интеграции с CRM.

  • Еще одно следствие прошлого пункта: не всегда можно выгрузить данные в удобном формате. Вряд ли вы сможете сменить систему аналитики с переносом всех ваших данных.

Для кастомных систем аналитики.

Здесь дела обстоят ещё сложнее. Спроектировать и построить собственную систему аналитики непросто, так как может не хватить сил 1-2 штатных разработчиков, а надеяться получить такой результата от фрилансеров ещё более опрометчиво. В любом случае, прежде чем приступать к разработке, стоит чётко определить:

  • Источники данных чем их меньше, тем проще;

  • Какие данные потребуются и как их объединять;

  • Выбрать систему визуализации и продумать форматы отчётов.

Наибольшие проблемы обычно возникают с выгрузкой и объединением данных. Не все системы позволяют выгружать не агрегированные данные. У многих систем есть ограничения по числу запросов по API.

Если не говорить о крупных компаниях (в штате которых есть и разработчики, и аналитики, у которых уже построен корпоративный DWH), для выгрузки данных лучше воспользоваться готовыми коннекторами, а для визуализации популярными на рынке решениями, такими как Microsoft Power BI или Google Data Studio.

Модели атрибуции

Зачем нужна атрибуция

Стандартно воронка продаж имеет четыре этапа:

  • Человек знакомится сторговой маркой;

  • Он знает окомпании, норазмышляет, совершатьли покупку, и поэтому проводит сравнение стоимости ианализирует характеристики предлагаемого товара;

  • Этап конверсии покупка совершается;

  • Этап удержания покупатель повторяет покупку.

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

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

Чтобы разобраться, какие используемые рекламные каналы икампании срабатывают наэтапах имеющейся воронки, необходимо воспользоваться атрибуцией.

Атрибуция это распределение ценности от конверсии между кампаниями, которые продвигали пользователя по воронке. Она помогает ответить на вопрос, в какой мере каждый из каналов повлиял на ту прибыль, которую вы получили в итоге.

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

Доступные модели атрибуции

Моделей атрибуции много, иони поддаются определенной классификации. Опираться нужно нато, какая именно логика применяется вовремя расчета:

  • Если вся ценность отдана единственному каналу, участвовавшему вворонке, то это одноканальная модель атрибуции;

  • Если обратить внимание наместо канала вцепочке непосредственно перед покупкой, то применяется атрибуция наоснове позиции;

  • Если распределение происходит между всеми участвовавшими вцепочке каналами, то это многоканальная модель;

  • Если врасчет берутся прочие факторы нетолько позиция, то алгоритмическая.

Позиции канала в цепочке

Данные варианты считаются наиболее простыми, они доступны пользователям бесплатной версии Google Analytics, а также Яндекс.Метрики и других систем. Рассмотрим 6 позиций канала в цепочке.

First Click (FCM)

Вцепочке изчетырех касаний ценность уходит первому каналу.

Преимущества:

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

Недостатки:

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

Кому подходит:

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

Last Click (LCM)

Одноканальная модель, где ценность конверсии передается последнему каналу, скоторым покупатель соприкасается непосредственно перед конверсией. Снова вклад предыдущих каналов полностью игнорируется.

Преимущества:

Используется многими маркетологами. Позволяет оценить кампании, цель которых быстро спровоцировать покупки, допустим, вовремя определенного сезона.

Недостатки:

Недемонстрирует всей картины, заставляя исключить прочие каналы цепочки.

Кому подходит:

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

Last Non-Direct Click (LN-DC)

Одноканальная модель, которая представлена вGoogle Analytics, применяется там поумолчанию. При этом ценность конверсии атрибутируется, как ивпредыдущем варианте, по последнему каналу.

Однако различие втом, что если это прямой заход, ценность будет атрибутирована предыдущему источнику.

Например, пользователь переходит изсобственных закладок илиже прямо вводит ссылку. Вероятно, он хорошо знает бренд, является уже привлеченным покупателем, которого нетребуется брать врасчет.

Преимущества:

Вэтом случае можно исключить каналы, которые незначительны сточки зрения расходов накампанию, полностью сосредоточившись наоплачиваемых источниках.

Может применяться вкачестве базы для сравнения.

Недостатки:

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

Кому подходит:

Модель подходит, если нужно оценить эффективность определенного платного канала, аузнаваемость бренда уже неявляется важным аспектом.

Position Based(PB)

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

Преимущества:

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

Недостатки:

Случается, что именно средние каналы вцепочке больше продвигают покупателя, чем те, которые получают наибольшую ценность.

Кому подходит:

Этот вариант подойдет бизнесам, которые рассчитывают привлекать новых пользователей иподталкивать уже заинтересованных ксовершению покупок.

Time Decay(TD)

Вэтом случае ценность конверсии будет распределена между каналами, которые заняты вцепочке, попринципу нарастания. Первый источник получает наименьшую ценность, последний наибольшую.

Преимущества:

Рассматриваются все каналы. Наибольшая ценность отдается тому, который всеже сумеет подтолкнуть кпокупке.

Недостатки:

Недооценивается вклад отдельных каналов, которые могли повлиять нарешение покупателя.

Кому подходит:

Подходит тем, кто желает оценить эффективность рекламных кампаний, ограниченных повремени например, распродаж.

Linear model(LM)

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

Преимущества:

Более продвинутая, чем одноканальные модели. Позволяет учесть все каналы вцепочке, которые были задействованы перед покупкой.

Недостатки:

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

Кому подходит:

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

Насегодняшний день имеется ряд исследований, которые доказывают, что маркетологи вЕвропе, США или СНГ чаще всего обращаются кмодели LCM. LCM кажется наиболее понятной, хотя иобесценивает влияние всех каналов в цепочке, кроме последнего.

Причинами, почему наблюдается такая ситуация, можно считать следующее:

  • Непонимание потенциального эффекта отмоделей атрибуции, использующих более сложный расчет. Если прямо объяснить, что алгоритмические модели могут принести увеличение прибыли наопределенный процент, врядли маркетологи откажутся отэтого.

  • Заатрибуцию нет ответственного, т.е. разные маркетологи могут применять входе кампании различные варианты, что приводит ктому, что реальный доход оказывается меньше атрибутированного.

  • Слишком разрозненная информация. Google Analytics позволяет использовать стандартные отчеты, вкоторых, ксожалению, нет места офлайн-данным, ROPO-эффекту ит.д.

Если эти причины устранить, то проблема атрибуции будет решаться намного проще.

Обзор сервисов иинструментов

Организовать сквозную аналитику можно различными способами, далее представлены наиболее популярные сервисы иинструменты для этого.

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

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

Сервисы и инструменты для сквозной аналитикиСервисы и инструменты для сквозной аналитики

Типы сервисов иинструментов

Разделим представленные сервисы на3группы:

1. Недорогие сервисы всё в 1

Включают всебя базовую сквозную аналитику и другие инструменты для организации маркетинга и продаж, например:

  • CRM-система

  • Управление рекламой

  • Лидогенерация

  • Взаимодействия ссоцсетями

  • Создание landingpage

  • Виджеты настраницу, сайт (онлайн-консультант, обратный звонок ипр.)

  • Автоворонки

Типичные представители:

  • LPTracker.ru

  • Expecto.me

  • CarrotQuest.io

  • PrimeGate.io

Подходит для микробизнеса. Оплата сервиса врайоне 1тыс. рублей вмесяц.

2. Сервисы сквозной аналитики

Специализированные сервисы, дающие более глубокую икачественную аналитику. Обычно интегрируются сCRM, системами веб-аналитики и колл-трекинга. Некоторые структуры выросли как раз изэтих систем.

Типичные представители:

  • Roistat

  • Alytics

  • Comagic

  • Calltouch

Подходит для малого и среднего бизнеса. Бюджет врайоне 5-20 тыс. рублей вмесяц.

3. Кастомные решения

Подходит для среднего икрупного бизнеса. Бюджет зависит отчисла интегрируемых систем, объёма данных, типов отчётов имногих других параметров.

Обычно аналитическая система состоитизтаких компонентов,как:

  • Коннекторы сбора данных

  • База для хранения иобработки данных (ETL, DWH)

  • Аналитический модуль (отвечает залогику объединения данных на базе сквозных идентификаторов)

  • Система визуализации данных (обычно, BI) снастроенными отчётами

Коннекторы собирают данные изтаких систем,как:

  • Рекламные каналы

  • Сайт

  • CRM

  • Телефония, почта, каналы коммуникаций (если эти данные неагрегированы вCRM)

Для внедрения сквозной аналитики необходимы следующие инструменты:

CRM

Для интеграции подходит любая система, имеющая API ивозможность настройки кастомных полей.

Наиболее популярные вРФ:

  • Битрикс24

  • AmoCRM

  • RetailCRM

  • Microsoft Dynamics (вкрупных компаниях)

Наиболее популярные вмире:

  • SalesForce

  • MicroSoft Dynamics

Сквозные идентификаторы:

Обычно используется ClientID (Google Analytics), ивдополнение кнему можно взять другие например, UserID Яндекс.Метрики, CoMagic, собственный идентификатор.

Базы хранения иобработки данных:

Это может быть как облачное решение:

  • Google BigQuery

  • Microsoft Azure CosmosDB

  • Яндекс ClickHouse

  • Amazon Redshift

Так и локальная база, развёрнутая насобственном сервере или тоже воблаке:

  • MySQL

  • MSSQL

  • PostgreSQL

Коннекторы:

  • Коннекторы собственной разработки;

  • Публичные коннекторы систем исторонних разработчиков (например, для Google Analytics, Google Data Studio, Microsoft Power BI, существует множество бесплатных коннекторов кразличным системам);

  • Сервисы коннекторов данных, например:

OWOX BI Pipeline

Albato.ru

apix-drive.com

supermetrics.com.

Системы визуализации:

  • BI-системы, такиекак:

Google Data Studio

Microsoft PowerBI

Qlik Sense /View

Tableau

  • Дашборды, построенные набазе публичных сервисов

  • Кастомные дашборды например, наD3.js

Другие системы:

  • Системы автоматизации контекстной рекламы иуправления ставками (например, Origami, Alytics, K50, Marilyn);

  • ERP, системы управления складом.

Интересно, что ванглийском языке нет общего термина для сквозной аналитики. Среди зарубежных систем принципы используются теже самые, нонатермине никто незацикливается. Есть business analytics, business intelligence, ROMI analytics, LTV analytics. Существуют также end-to-end analytics иcross-cutting analytics, но упоминаются редко. Наверное, там всем понятно, что аналитика должна быть сквозной поопределению.

Рекомендации по внедрению сквозной аналитики

Подводя итог, если вы загорелись идеей внедрения сквозной аналитики, помните:

  1. Самое сложное ненастроить BI-систему для отображения нужных графиков, авнедрить CRM так, чтобы все данные проходили через неё. Если CRM уже внедрена, построение сквозной аналитики сильно упрощается. Нотолько если это популярная облачная CRM изнебольшого списка, аненекая малоизвестная инеимеющая API. Если увас не популярное решение без API, сложность задачи становится равносильной оной при отсутствииCRM.

  2. Чтобы отCRM была реальная польза, ей следует быть омниканальной, видеале все лиды совсех каналов должны попадать внеё автоматически. Нопри этом CRM может успешно работать без интеграции сERP. Если увас старая 1С, ипридётся выставлять счета вручную без синхронизации, то это проблема, которая несильно мешает внедрению CRM иработе вцелом.

  3. Прежде чем начинать, нужно быть готовыми ксложностям иктому, что интеграции в1клик работают невсегда иневсегда дают полную интеграцию внужном виде, азначит только API, только хардкор. Готовых решений нет ни укого. Увсех своя специфика, нодаже набазе самых популярных CRM (Битрикс иАmo), самой популярной системы сквозной аналитики (Roistat), самого популярного движка сайта (Битрикс), самой популярной SIP-телефонии, самых популярных консультантов (Живосайт или Livetex) нет работающей интеграции всего ився изкоробки так, как этогобы хотелось.

  4. Если вы владелец бизнеса, сначала оцените, сколько времени иденег уйдет, потом умножьте на3иподумайте, стоитли делать сейчас или позже. Стоитли делать всё сразу (внедрять CRM, запускать рекламу инастраивать сквозную аналитику) илиже можно поочереди (сначала CRM иреклама). Сквозная аналитика нужна, когда увас много каналов привлечения трафика. Если увас пока только Яндекс.Директ, то выгодней сначала подключить Google.Ads идобиться там схожей стоимости лида, ауже потом настраивать сложные системы.

  5. Недумайте, что вбольших кампаниях дела обстоят лучше. Крупный бизнес вообще неотдаст данные изCRM стороннему сервису (защита персональных данных). Поэтому маркетологи вбрендах думают вкатегориях обезличенных сегментов, анеоuser_id. Даже вкрупном ритейле бывает так, что информация омаркетинговых акциях заносится в разное ПО(кассовое, CRM ит.д.), инет единой базы, ROI акций несчитается.

  6. Последнее иглавное. Несмотря навсе сложности, сквозная аналитика всё-таки жизненно необходима для построения бизнеса вусловиях высокой конкуренции.

Как считали эффективность рекламыКак считали эффективность рекламы

Куда движутся системы сквозной аналитики

Трудно сказать наверняка, но есть некоторые предположения:

  • Упрощение истандартизация интеграций. Пока идёт этап интеграции всего совсем, носкоро насыщение будет достигнуто, иостанется только упрощать интеграцию до1клика идобавлять тонкие настройки винтерфейс вместо текущих скриптов ивебхуков.

  • Замена маркетинговых метрик набизнес-метрики. Т.е. изинструмента маркетолога система превращается винструмент для всех маркетолога, аналитика, РОПа, генерального директора, собственника бизнеса. Дашборды должны гибко настраиваться под каждого сотрудника.

  • Увеличение точности данных засчёт более сложных моделей атрибуции иразделения алгоритмов порыночным нишам/ портретам клиента. Модель атрибуции должна быть умной, наоснове воронки и всех имеющихся данных. Представьте, что мы оцениваем вклад рекламного источника, втом числе анализируя записи разговоров клиента сменеджером. После однойрекламы звонок был поделу ипривёл кпродаже. После другой звонок был, нокпродаже непривёл. Алгоритм могбы распознать голос ипроанализировать стой или иной степенью достоверности, виноватли менеджер, или, например, реклама обещала что-то несоответствующее действительности.

  • Помимо имеющихся метрик, можно ввести коэффициент лояльности % влияния рекламы наповторную покупку. От0(повторную продажу делает только реклама) до100% (повторная продажа совершается независимо отрекламы). Коэффициент зависит ототрасли, известности бренда, его программ лояльности и,конечно, уникальности продукции.

  • Незабываем добавлять k-factor, т.е. рекомендации банальный сарафан. Если средний ваш клиент приводит ещё 0,5клиента, неверно это игнорировать при подсчёте эффективности маркетинга. ROMI иLTV нужно считать сего учётом.

  • Помимо предоставления набора дашбордов, BI-системы движутся всторону поиска наестественном языке. Т.е. системы должны двигаться всторону интеллектуальности иизмаркетингового инструмента превращаться вбизнес-инструмент.

    Что же, надеемся увидеть много интересного вбудущем!

Желаюудачиво внедрении сквозной аналитики!

Подробнее..
Категории: Повышение конверсии , Веб-аналитика , Интернет-маркетинг , Контекстная реклама , Roi , Бизнес-аналитика , Сквозная аналитика , Эффективная реклама , Romi , Возврат инвестиций

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru