Системный и бизнес-анализ

Привет! Меня зовут Любовь Черкасова. Я больше 13 лет работаю в ИТ и занимаюсь цифровизацией бизнес-процессов в крупных компаниях. За это время я руководила командами аналитиков и отделом внедрения, участвовала в проектах по запуску и развитию корпоративных систем, а также выводила на рынок собственный продукт — LDM.КЭДО.

Последние годы я занимаюсь развитием CSP-платформы в LDM и наша команда регулярно проводит исследования. За три месяца в прошлом году нам удалось провести более 50 интервью с ИТ-директорами, руководителями внедрения, сопровождения и цифровой трансформации в крупнейших российских компаниях. 

Работа в продуктовых командах часто разделяется на 2 этапа: исследования (Discovery) и разработка (Delivery). Этап Discovery направлен на проверку жизнеспособности идеи, чтобы не тратить на разработку много человеко-месяцев. В некоторых случаях, дешевле разработать, запустить и проверить все на практике, но если мы говорим о длительной и дорогой разработке — цена ошибки может быть слишком высока, поэтому дешевле сначала провести исследование.  О важности этапа Discovery написаны сотни книг, но большинство примеров в них сводятся к B2C: «Почему люди покупают именно эту марку молока». Когда речь заходит о B2B-метриках, становится сложнее: как рассчитать retention бухгалтеров в ERP или ценность системы управления контентом (ECM)?

В B2B ценность Discovery выше, но и порог входа другой: вы не можете просто встать у полки в супермаркете — вам, как минимум, нужно подписать NDA. Мы провели масштабное исследование опыта использования систем управления контентом (OpenText, SharePoint, FileNet) в России и готовы поделиться «кухней» процесса.

Привет, Хабр! Меня зовут Николай Щедрин, я ведущий аналитик Сбера. В этой статье продолжаю делиться инсайтами по использованию ИИ‑ассистентов в работе бизнес‑ и системного аналитика. Первую часть я публиковал на Хабре в прошлом году.

Сегодня поговорим о разработке собственного проекта через описание требований в .md‑файлах.

Даже беглый анализ некоторых текстов группы "Кино" наталкивает на мысль о довольно сильных символических значениях их стихотворных строк. Мне стало интересно провести сравнительный анализ текста песни Виктора Цоя и драмы Уильяма Шекспира "Гамлет" и найти пересечения, аллюзии и реминисценции в творчестве двух авторов помощью инструментов NLP на Python.

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

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

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

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

Большинство устройств в цифровом мире живёт по тактам. Процессор Intel i5 крутит свой цикл: выборка инструкции, декодирование, исполнение, предсказание перехода - и всё это миллиарды раз в секунду. У GPU от NVIDIA - совсем другой ритм: параллельные потоки, массовые вычисления, другая логика загрузки и исполнения. Архитектуры разные - но принцип один: есть повторяющийся рабочий цикл. У человеческого мышления тоже есть свой такт. Он не измеряется гигагерцами. Один его «оборот» может занять вечер, неделю или несколько лет. Но если присмотреться, в нём повторяются одни и те же фазы: мы вводим понятия, формулируем тезисы, строим модели, и т.д. . Потом цикл начинается заново - уже на новом уровне. Это не биологическая прошивка и не нейронный микрокод. Это культурно сформированная архитектура мышления. Та версия рациональности, которая сложилась в европейской традиции - от античной логики до научного метода - породила довольно специфический когнитивный ритм. При этом понятно, что в другой цивилизационной культуре, например китайской, такт познания может быть несколько иным.

В данной статье детально рассматривается такт мышления европейского рационального сознания. А разные шаги этого такта - как основные маркеры (типы) для публикации/поиска идей в базе знаний.

Об опыте прохождения курса от Яндекс "Инженер данных с нуля", что подвинуло, как учился, какие претензии, стоит ли он своих денег. В общем - мысли в слух!

Самые интересные новости финансов и технологий в России и мире за неделю: Пентагон поменял Claude на ChatGPT, мировые рынки паникнули из-за статьи про безработицу и AI в Substack, Block сократил почти половину сотрудников «благодаря ИИ», на рынках предсказаний пачками разоблачают инсайдеров, в РФ основали комиссию по AI (с ФСБшниками), а также уголовное дело против Дурова.

В статье разберем реальную задачу аналитика ассортимента в ритейле: «Какие товары люди покупают вместе», на учебных данных, с кодом SQL, со всей необходимой математикой и с примером выводов.

Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.

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

В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.

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

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

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

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

Data Mesh, Data Fabric, Lakehouse: разбираем модные термины

Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.

➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.

✔️Сохраняйте, чтобы больше никогда не путаться.

Представим ситуацию.

Маркетолог работает в крупной компании с собственной A/B-платформой. Каждый квартал он должен запускать несколько новых маркетинговых кампаний, и подтверждать их эффективность с помощью экспериментов. Ресурса аналитика всегда не хватает на подобные задачи. А A/B-платформа позиционируются как инструмент, доступный в том числе маркетологам и проектным менеджерам. В итоге, наш герой решает запустить эксперимент самостоятельно.

Гипотеза. «Новый лендинг увеличивает среднюю выручку на пользователя (ARPU) в выбранном сегменте».

Спустя несколько недель маркетолог открывает AB-платформу, чтобы подвести итоги эксперимента. Видит, что пользователи распределены по группам примерно равное: 9 936 в тесте и 10 068 в контроле. Результат радует глаз: effect = 18.28%. "Какой эффект! Вот только чувствительности для "прокраса" немного не хватило", - думает он, - "глядя на p-value = 0.1179".

Но можно ли принимать решения на основе этих данных? Давайте разберемся, проведя анализ вероятных искажений.

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

🔹 Бесплатные курсы, которые дают реальную базу (и где искать правдивые отзывы)
🔹 Как подружиться с ИИ и заставить его работать вашим личным наставником
🔹 Честный тест-драйв: как понять, что аналитика – это ваше, до покупки курса
🔹 Когда идти на платное обучение и как выбрать курс, чтобы не выбросить деньги на ветер

«Зачем мне эта ваша математика?» честный разбор для тех, кто хочет расти в аналитике

Если вы работаете в аналитике и ни разу не задавались вопросом «а зачем мне эти интегралы и производные» – вы либо гений, либо врете.
В интернете много статей про матан для аналитиков, но они либо уходят в дебри интегрирования по частям, либо ограничиваются уровнем «логарифм делает большие числа маленькими». Где золотая середина?

Что внутри:
Логарифмы: не просто log1p, а эластичность и среднее геометрическое
Производные: как поймать момент перед падением (вторая производная)
Пределы: почему retention не упадет ниже 15% (и при чем тут асимптоты)
Интегралы: LTV с дисконтированием и площадь под uplift-кривой

Для кого: аналитики, которые уже вышли из Excel и хотят понимать, что на самом деле делают их .diff() и .cumsum().

Корпоративный мир ушёл далеко вперёд. Если 10 лет назад сотрудники выходили на работу, чтобы создавать продукты «с нуля», то сегодня конъюнктура изменилась. IT-ландшафт крупных компаний перенасыщен решениями на любой вкус. На смену классическому проектному управлению, ориентированному на создание чего-то нового, пришло управление продуктами, где гибкие методологии работают на развитие и стабилизацию уже существующих систем.

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

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

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.