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

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

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

Помимо общего знакомства с концепцией DWH, фокус доклада сосредоточен на том, что же конкретно делает аналитик на проекте DWH? Сложно это или просто? Какими компетенциями должен обладать такой аналитик и какие прикладные задачи он решает? 

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

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

Я прошла путь от осознания и принятия выгорания, потом «лечила» это долгим отпуском (5 месяцев). Нашла в себе силы и смыслы вернуться в аналитику и уже полгода работаю в команде мечты, контролирую свое состояние. 

Поговорим о том, всем ли подходит этот вариант «лечения», как к нему подготовиться, чем можно заняться и как потом вернуться к работе.

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

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

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

Поделимся опытом оптимизации и повышения эффективности в команде за счет развития своих навыков по модели T-Shaped.

На примере задач расскажем какие навыки и инструменты полезны системному аналитику. Также рассмотрим возможное участие аналитика в смежных ролях. Приведем преимущества такого подхода для специалиста и команды в целом.

Содокладчик: Любовь Кислова

Про проектирование, моделирование ИС написано большое количество книг и статей, сделано значительное количество интересных докладов. Но несмотря на весь это без сомнения полезный труд, что многие из нас видят в проектах, продуктах или любом другом процессе или подходе, направленном на создание ИС, программные продуктов, сервисов и т.п.?
"Пилите таски из jira!". Вот и вся работа. А результаты проектирования пыляться и скучают где-то в килотоннах документации (если она есть), или находятся в голове 5% старожилов команды и строго хранятся этим орденом. Конечно, это скорее преувеличение, но тем не менее зачастую моделирование и проектироание или не включено в поток, или в ключено, но очень слабо.

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

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

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

- соблюдать договоренности внутри команды / внутри проекта,

- учитывать справочные значения в интеграционных интерфейсах.

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

- работу с пустыми и отсутствующими значениями,

- работу со всевозможными маппингами (преобразованиями) между разными интеграционными слоями,

- обработку ошибок на всех ветках алгоритма,

- сокращение Http Status Code = 500.

Если следовать этим принципам и учитывать нюансы, то "блох" интеграции, выявленных при тестировании и при выходе в ПРОД, будет в разы меньше.

В классических книгах по системному анализу, переведенных на русский язык, понятие потребность раскрывается недостаточно точно. В книге и на курсах системного мышления А. Левенчука (основанных на теории системной инженерии) это определяется как требование к надсистеме. Однако при изучении JTBD и техник user story и job story оказывается, что есть более удачные концепты. Кроме того сама техника job story часто ошибочно воспринимается, как конкурент user story, во многом из-за недостаточного материала и выступлений. В докладе мы пробежимся по базовым необходимым понятиям системной инженерии и дадим более удачное определение потребности, источника ее возникновения, разбиению на уровни системы и слоям (проблема-решение) и выразим user story, job story в этих смыслах. Нельзя сказать, что эта теория всеобъемлющая, так как опыт применения этого у автора в основном в ритейле при проектировании бизнес-процессов и их автоматизации, но, возможно, она будет полезна и в других сферах. 

Перед выступлением будет полезно ознакомится с текстом https://habr.com/ru/post/529236/ или видео https://youtu.be/TbDnSQbMGjg  о ценности, создаваемом ИТ аналитиком для бизнеса.

Что ожидает бизнес, когда обращается к ИТ за автоматизацией? Что такое “полезная” автоматизация и когда бизнес будет действительно благодарен ИТ за автоматизацию процессов? А кто такой “Бизнес”, когда он выступает как заказчик информационной системы? Как c ним конструктивно взаимодействовать, чтобы Бизнес относился к ИТ как к уважаемым консультантам, а не как к еще одной затрате?  Часто аналитики жалуются на то, что им недостаточно полномочий для влияния на бизнес-процессы заказчика и их никто не слушает, по сути заставляя создавать систему под устоявшиеся процессы. Почему так происходит? Все эти вопросы не так просты, и ответ на них получаешь только c длительным опытом, поработав c двух сторон: и как ИТ-специалист, выполняющий заказ, и как бизнес, обращающийся к ИТ за услугами. Поработав c двух сторон, мышление меняется. Если удовлетворить все собранные требования к системе, точно ли она  будет полезна? 

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

В основном мы будем говорить о заказной разработке.