Незаменимый в команде
Показать полностью
2
0 просмотренных постов скрыто
Системный аналитик: востребовано ли
Всем доброго дня!
Это мой первый пост и прошу прощения, если что-то не так. Хотел бы узнать мнение людей, которые непосредственно работают в IT-сфере, а именно в системном анализе.
Я обучался в универе по специальности «Бизнес-информатика», но судьба меня завела в совершенно другую сферу.
Хочу вспомнить былое и переквалифицироваться на системного аналитика. Понимаю, что это лишь поверхностное изучение и нужно самому углублено все изучать и совершенствоваться, однако сейчас мой вопрос в другом: насколько полезно будет обучение системному анализу, например, в Яндекс практикуме и насколько эта специальность сейчас востребована? Можно ли найти работу стажера/джуниор и насколько это сейчас вообще возможно?
Когда TO BE стал копией AS IS. Часть 2: аналитик, который изучил всё
Часть 2: аналитик, который изучил всё
Начало. Снова всё правильно
В прошлый раз его подвела слепота к людям. В этот раз — методология.
Задача звучала знакомо: перевести офлайн-ритейлер в онлайн, спроектировать интернет-магазин. Постановка была короткой и на вид безупречной — «изучить всё как есть, спроектировать как должно быть».
Аналитик изучил всё. Оргструктуру, ценообразование, сборку, перемещение между складами, доставку, возвраты, приёмку товара, сверку с бухгалтерией. Десятки процессов, сотни шагов, аккуратные схемы AS IS. Работа на загляденье.
Разве не молодец?
Первый звонок. TO BE рождается похожим
Началось проектирование TO BE. И оно стало обрастать знакомыми чертами.
Приём заказов проектировался по образу приёма заявок в офлайне. Информирование покупателя — как обзвон менеджером. Оплата — как касса на входе. Каждый новый процесс аналитик невольно лепил из уже описанного старого.
Он поймал себя на этом не сразу. А когда поймал — списал на сопротивление команды, как в прошлый раз. Но команда была ни при чём. В этот раз якорь он принёс сам.
Смена угла зрения. AS IS — не для того, чтобы его описать
Аналитик остановился и задал вопрос, который стоило задать до, а не после: зачем вообще нужен AS IS?
Не чтобы задокументировать текущую систему во всей красе. AS IS нужен, чтобы понять, на каком фундаменте мы строим TO BE и что именно из старого TO BE наследует.
Интернет-магазин наследует у офлайна не всё. Ценообразование, сборку, перемещение, доставку — да, это фундамент. Но интерфейс покупателя, приём заказов, приём оплат, информирование о статусе — это новое, уникальное, и лепить его из старого нельзя.
Значит, «изучить всё» — не добродетель. Это крайность. Аналитик копал офлайн-кассу с той же глубиной, что и сборку, — и офлайн-касса протекла в дизайн онлайн-оплаты.
Ошибка. Почему «изучить всё» — это не глубина
Тут прячется ловушка, которую видно не сразу.
Кажется, что проблема в объёме — изучил слишком много, потратил время. Но настоящий вред тоньше: **чем детальнее описан старый процесс, тем труднее от него отказаться.** Подробный AS IS легитимизирует текущий порядок. Аналитик, вложивший неделю в схему офлайн-приёма заказов, бессознательно защищает её в TO BE. Он построил не фундамент. Он построил якорь.
И «изучить всё» проваливает не глубину. Оно проваливает **зонирование**. Оно заставляет копать то, что вообще не станет частью нового решения, так же тщательно, как то, что станет его спецификацией.
Карта. Четыре связи с AS IS, а не одна
Аналитик понял: наследование — не единственная нить между старым и новым. Их четыре, и глубина изучения зависит от того, какая именно связывает фрагмент с TO BE.
Наследуем. Процесс переходит в TO BE почти как есть — ценообразование, сборка, доставка. Его нужно описать полно: это готовая спецификация.
Заменяем. Приём оплат, интерфейс покупателя. Внутрь старого процесса лезть не нужно — но нужен контракт на его границе: что на входе, что на выходе, какие данные, какие бизнес-правила. Здесь же прячется коварство: «приём оплат» объявляют уникальным для онлайна — а он сидит в эквайринге, сверках и возвратах. Граница важнее внутренностей.
Не трогаем, но стыкуемся. Бухгалтерия, склад-система — их не переписываем, но TO BE обязан сохранить контракт с ними. Нужен только интерфейс.
Не трогаем и не стыкуемся. Всё остальное. Одна строка: «существует».
Четыре связи AS IS с TO BE: наследуем, заменяем, стыкуемся, не связан
Противоречие. AS IS надо изучить полностью — и нельзя
Вот напряжение, которое аналитик наконец увидел ясно.
AS IS надо изучить полностью — иначе теряются скрытые ограничения и стыки. Странный шаг в старом процессе часто кодирует регуляторное или договорное требование; выбросишь его как «легаси» — переоткроешь в проде.
AS IS нельзя изучать полностью — это дорого, а главное, детальный AS IS легитимизирует старое. Чем подробнее описал — тем сильнее якорь.
Это и есть механизм, из-за которого TO BE становится копией AS IS. Не вопреки качественному AS IS. Из-за него.
Разрешение. Два прохода вместо одного
Противоречие снимается разделением во времени. Не один тщательный проход по всему — а два разных.
Проход 1 — широкий и мелкий. Карта всех процессов на один уровень, без деталей. Единственная цель — найти границы и стыки, разложить процессы по четырём зонам. Здесь же рождается гипотеза TO BE: что наследуем, что заменяем.
Проход 2 — узкий и глубокий. Только по зонам «наследуем» и «заменяем». Первый проход дал вход для гипотезы TO BE — гипотеза TO BE задала глубину второго прохода.
Круг размыкается: раньше, чтобы понять, что изучать глубоко, нужно было уже знать AS IS. Теперь первый проход отвечает на этот вопрос дёшево, а второй тратит силы только там, где они станут спецификацией.
Два прохода вместо одного: широкий-мелкий, гипотеза TO BE, узкий-глубокий
Что изменилось
Аналитик не стал изучать меньше из лени. Он стал изучать прицельно.
Офлайн-касса получила одну строку и контракт на границе. Сборка и доставка — полное описание. Приём заказов проектировался с чистого листа, потому что аналитик больше не держал перед глазами подробную схему старого приёма заявок, от которой не мог оторваться.
TO BE перестал быть копией AS IS. Не потому что команда стала смелее. Потому что аналитик перестал приносить якорь под видом фундамента.
Детальность AS IS — не добродетель, а риск. Аналитик, изучивший всё, построил не фундамент, а якорь. Задача — не описать текущую систему целиком. Задача — понять, что из неё переживёт переход, и изучить глубоко только это.
Показать полностью
3
Нагрузочное тестирование: зачем оно нужно и как быстро сгенерировать миллионы записей в Oracle
Когда мы разрабатываем систему, чаще всего тестируем её на небольшом объёме данных: несколько десятков или сотен записей. Но в реальной эксплуатации база может содержать миллионы строк, а одновременно системой могут пользоваться тысячи пользователей.
Именно поэтому перед вводом системы в эксплуатацию проводят нагрузочное тестирование.
В канале Аналитика FM я публикую реальные запросы SQL с разбором логики. Обсуждаем продуктовые метрики и как правильно строить аналитику данных.
Канал веду с нуля подписчиков.
Подписывайся, если тоже хочешь вникнуть в прекрасный мир аналитики.
Нагрузочное тестирование - это проверка работы системы под нагрузкой, максимально приближенной к реальной.
Его цель - ответить на вопросы:
Сколько пользователей одновременно выдержит система?
Как быстро будут выполняться запросы?
Как изменится производительность при увеличении объёма данных?
Не начнёт ли база данных работать значительно медленнее?
Не возникнут ли ошибки из-за нехватки памяти, места во временном табличном пространстве или перегрузки процессора?
Например, запрос, который за 0,1 секунды обрабатывает 100 строк, может выполняться несколько минут при таблице в 100 миллионов записей.
Поэтому проверять производительность необходимо именно на объёмах, близких к реальным.
Какие бывают виды нагрузочного тестирования?
1. Load Testing (нагрузочное тестирование)
Проверяется работа системы при обычной ожидаемой нагрузке.
Например:
одновременно работают 500 пользователей;
таблица содержит 10 миллионов записей.
2. Stress Testing (стресс-тестирование)
На систему специально подают нагрузку выше расчётной.
Цель - определить предел её возможностей и понять, как она поведёт себя при перегрузке.
3. Volume Testing (тестирование объёма данных)
Проверяется влияние количества данных на производительность.
Например:
запрос работает с таблицей из 100 тыс. строк;
затем с 10 млн;
затем со 100 млн.
4. Endurance Testing (тестирование на длительную работу)
Система работает под постоянной нагрузкой несколько часов или даже суток.
Проверяют, не возникает ли утечек памяти и деградации производительности.
Как подготовить данные для нагрузочного тестирования Oracle?
Самый простой способ - сгенерировать тестовые записи прямо средствами Oracle.
Например:
SELECT 'ООО Ромашка ' || LEVEL AS name,
7700000000 + LEVEL AS inn,
1027700000000 + LEVEL AS ogrn
FROM dual
CONNECT BY LEVEL <= 1000000;
Этот запрос создаст 1 миллион строк без использования каких-либо таблиц.
И так вы сможете подготовить базу с наполненными данными для тестирования нагрузки.
Иногда такого подхода не хватает, и данные должны быть консистентными, иметь логическую зависимость от других параметров. Но это уже более глубокая семантика нагрузочного тестирования.
А мы с вами начинаем познавать увлекательный мир аналитики и данных.
Разбор скрипта проведем в канале Аналитика FM.
Подписывайся, чтобы узнавать техническую сторону работы аналитика.
Показать полностью
1
Пять отчетов, которые помогают держать бизнес под контролем
Управлять магазином — значит каждый день что-то решать: что закупить, какую выставить цену, кого из сотрудников премировать. Делать это на ощупь сложно и дорого. Чтобы держать руку на пульсе, хватит пяти отчетов — разберем, на какие смотреть и как их читать.
Выручка
Сумма за день сама по себе мало о чем говорит: 100 000 рублей — это много или недостаточно? Поэтому выручку нужно смотреть в динамике и сравнивать с прошлым периодом — вчера, неделю или месяц назад. Полезно разделять выручку с НДС и без, а еще отдельно считать товары и услуги.
Снимать суммы с кассы вручную, переносить в таблицу, вбивать формулы — на это уходит время, которого у предпринимателя обычно нет. Поэтому проще, когда данные собирает сама касса.
Онлайн-кассы АТОЛ передают каждую продажу в личный кабинет АТОЛ SIGMA, а там отчет «Выручка» показывает приток денег с точностью до дня и позволяет сопоставить его со средним чеком, количеством чеков и маржинальностью. Открыли кабинет — и видите картину, без ручных таблиц.
Рейтинг товаров и услуг
Показывает динамику спроса на самые ходовые позиции, полный список товаров по популярности и сравнение их по выручке, себестоимости и марже. Поможет выяснить, что из ассортимента реально продается, а что просто занимает полку.
Здесь легко попасть в ловушку. Товар может быть популярным, но низкомаржинальным. Бывает и наоборот: скромная по объему продаж позиция иногда приносит основную прибыль. Поэтому смотреть только на «топ товаров» недостаточно, в голове нужно держать еще и маржу.
Лидеров рейтинга стоит беречь: следите за их остатками на складе, потому что перебои с поставками ходового товара бьют по выручке сразу. А неходовые позиции, которые месяцами лежат мертвым грузом, разумнее распродать и вывести из ассортимента.
В личном кабинете АТОЛ SIGMA отчет «Рейтинг товаров» связан с товароучетом: видно и спрос, и складские остатки, так что заказы к поставщику проще планировать — понятно, чего и сколько брать.
Средний чек и количество чеков
Эти два показателя удобно читать в паре: вместе они объясняют, за счет чего меняется выручка.
Первый показывает, сколько в среднем тратит покупатель за один визит. Считается просто: выручка делится на количество продаж. Поднять средний чек часто проще, чем привести новых клиентов, — достаточно научить кассиров предлагать сопутствующие товары.
Самое интересное начинается, когда вы смотрите на них вместе. Выручка растет, а чеков столько же или меньше — значит, персонал стал лучше работать с каждым клиентом. Выручка падает при том же числе чеков — повод присмотреться, как продавцы общаются с покупателями.
В аналитике АТОЛ SIGMA оба показателя выведены отдельными блоками, причем с разбивкой по точкам и сотрудникам. За пару минут вы увидите, где именно просел средний чек.
Лояльность клиентов и отзывы
Привлечь нового покупателя дороже, чем удержать старого.
Этот отчет показывает поведение клиентов: сколько их было, какие товары они предпочитали, каким способом платили, приходили ли повторно и как оценивали магазин.
Если в одной из точек повторных визитов заметно меньше, чем в остальных, это сигнал: возможно, дело в сервисе, ассортименте или очередях.
АТОЛ SIGMA покажет отдельные блоки по визитам и лояльности с отзывами, а клиентская база ведется прямо в кабинете. На этих данных удобно строить программы лояльности и понимать, кто ваши постоянные покупатели.
Рейтинг сотрудников
Предпринимателю важно знать, как работает каждый член команды: сколько продаж он совершил и сколько это принесло магазину выручки и маржи. Если кассиров много, без автоматизации не обойтись.
«Рейтинг сотрудников» в личном кабинете АТОЛ SIGMA показывает вклад каждого продавца в общий результат. Это помогает вовремя подмечать заслуги и планировать повышение квалификации.
Пример: выручка по новому сотруднику снижается, положительной динамики нет. Прежде чем расставаться, попробуйте поговорить, обучить, пересмотреть мотивацию. А если у одного кассира средний чек стабильно выше, чем у коллег, это вряд ли случайность: скорее всего, он активнее предлагает сопутствующие товары.
Что в итоге
Не пытайтесь объять все метрики сразу — выберите два-три самых важных показателя, например, выручку, средний чек и маржу, и отслеживайте их регулярно. Главное здесь — постоянство: сравнивать имеет смысл одинаковые периоды. Но помните: графики сами по себе ничего не меняют — ценность появляется в решениях, которые вы на их основе принимаете.
Хорошая новость в том, что всю сложную работу берет на себя техника. Онлайн-кассы АТОЛ фиксируют каждую продажу, а личный кабинет АТОЛ SIGMA превращает эти данные в наглядные отчеты и графики.
Реклама. ООО «АТОЛ», ИНН: 5010051677
Показать полностью
8
Иерархический справочник: когда данные растут как дерево
Представьте дерево. У него есть корень, от него отходят ветки, от больших веток - более мелкие, а затем листья.
Примерно так же устроены иерархические справочники в информационных системах.
И как же можно понять: что есть ветка, а что есть лист в этом иерархическом справочнике?
В канале Аналитика FM я часто разбираю такие ситуации - когда задача вроде решаема, но без нормальной структуры превращается в кашу.
Например:
📁 Транспорт
├── Легковой транспорт
│ ├── Седаны
│ └── Кроссоверы
└── Грузовой транспорт
├── Малотоннажный
└── Тягачи
Или:
📁 Товары
├── Электроника
│ ├── Телефоны
│ └── Ноутбуки
└── Бытовая техника
├── Холодильники
└── Стиральные машины
А как такое дерево хранится в базе данных?
На самом деле всё гораздо проще, чем кажется.
Обычно таблица справочника выглядит примерно так:
| id | name | parent_id |
| --- | ----------------------------------- | --------------- |
| 1 | Транспорт | NULL |
| 2 | Легковой транспорт | 1 |
| 3 | Грузовой транспорт | 1 |
| 4 | Седаны | 2 |
| 5 | Кроссоверы | 2 |
| 6 | Тягачи | 3 |
Структурно это выглядит так:
1 Транспорт
├── 2 Легковой транспорт
│ ├── 4 Седаны
│ └── 5 Кроссоверы
└── 3 Грузовой транспорт
└── 6 Тягачи
Каждая запись имеет:
id - собственный идентификатор;
parent_id - идентификатор родительского элемента.
Например:
id = 4
name = Седаны
parent_id = 2
Это означает:
Седаны → Легковой транспорт → Транспорт
Именно благодаря полю parent_id база понимает, что "Седаны" и "Кроссоверы" относятся к одной ветке дерева.
Если подниматься по родителям вверх, то рано или поздно мы придём к общему узлу - корню ветки.
Получается, что вся иерархия строится буквально на одном поле: parent_id
Для чего нужны иерархические справочники?
Они позволяют хранить данные не просто списком, а показывать связи между объектами.
Благодаря этому можно:
✅ группировать данные;
✅ строить отчёты по категориям;
✅ наследовать свойства от родительских узлов;
✅ задавать правила сразу для целой ветки;
✅ быстро находить все дочерние элементы.
Например, если правило применяется ко всей категории "Легковой транспорт", то оно автоматически действует и для седанов, и для кроссоверов, и для любых новых подкатегорий, которые появятся позже.
Где используются?
📌 MDM-системы (Master Data Management);
📌 каталоги товаров интернет-магазинов;
📌 банковские и страховые системы;
📌 ERP и CRM;
📌 классификаторы услуг и продуктов;
📌 организационная структура компании;
📌 государственные классификаторы и справочники.
Преимущества
✔ Гибкость. Можно добавлять новые ветки без изменения структуры данных.
✔ Удобная аналитика. Легко получить данные как по конкретному элементу, так и по всей категории.
✔ Наследование правил. Одно правило может применяться сразу к тысячам объектов.
✔ Масштабируемость. Структура может содержать десятки и сотни уровней вложенности.
Недостатки
❌ Сложность запросов. Иногда, чтобы найти всех потомков или родителей, приходится строить рекурсивные запросы.
❌ Производительность. Глубокие иерархии могут существенно замедлять выполнение запросов.
❌ Риск циклических ссылок. Если по ошибке сделать узел потомком самого себя, можно получить бесконечный цикл.
❌ Сложность сопровождения. Изменение структуры верхних уровней может затронуть большое количество дочерних элементов.
Как с ними работать?
При работе с иерархическими справочниками чаще всего приходится решать четыре задачи:
🔹 найти всех потомков узла;
🔹 найти всех родителей элемента;
🔹 определить, принадлежит ли элемент определённой ветке;
🔹 определить, к какому верхнему узлу относится конкретный элемент.
В Oracle для этого используются специальные иерархические запросы:
START WITH ...
CONNECT BY ...
Именно они позволяют "обходить дерево" вверх или вниз по веткам.
В канале Аналитика FM (клик :-) ) уже готов пост про конструкцию START WITH и CONNECT BY.
Подписывайся, если интересно разбираться в особенностях работы аналитика.
Иерархический справочник - это не просто список значений. Это способ описать реальные взаимосвязи между объектами и сделать систему более гибкой и управляемой.
А одна маленькая колонка parent_id превращает обычную таблицу в целое дерево данных.
Показать полностью
1
Временные таблицы в базе данных
Если ты когда-нибудь писал длинный SQL-запрос и в какой-то момент ловил себя на мысли:
"Я уже сам не понимаю, что здесь происходит" - поздравляю, ты подошёл к моменту, где появляются временные таблицы.
В канале Аналитика FM я часто разбираю такие ситуации - когда задача вроде решаема, но без нормальной структуры превращается в кашу.
Что такое временная таблица
Это обычная таблица…
только с одним отличием:
👉 она живёт временно и потом исчезает
Ты создаёшь её:
чтобы сохранить промежуточный результат
поработать с ним
и не засорять основную базу
Тебе нужно:
взять заказы
отфильтровать только оплаченные
посчитать выручку
добавить сегментацию пользователей
ещё пару условий сверху
Можно написать один огромный запрос.
А можно сделать по-другому:
Сначала собрать "чистые заказы"
Потом на их основе считать метрики
Потом добавлять бизнес-логику
И вот тут временные таблицы начинают играть.
Как это выглядит
CREATE TEMP TABLE temp_orders AS
SELECT *
FROM orders
WHERE status = 'paid';
Создаем промежуточный слой данных.
А потом работаем уже с ним.
SELECT user_id, SUM(amount)
FROM temp_orders
GROUP BY user_id;
Зачем это нужно
1️⃣ Разделить сложную логику
Вместо одного "монстра":
ты разбиваешь задачу на шаги
каждый шаг понятен
легче дебажить
2️⃣ Переиспользовать результат
Если один и тот же кусок данных нужен несколько раз:
не нужно каждый раз пересчитывать
можно сохранить и использовать
3️⃣ Ускорить запросы
Иногда:
тяжёлый JOIN
сложная фильтрация
👉 выгодно посчитать один раз и сохранить результат
4️⃣ Не засорять базу
Если ты создашь обычную таблицу:
она останется
её надо потом удалять
она может мешать другим
Временная таблица:
живёт в рамках сессии
автоматически исчезает
Когда это особенно полезно
сложные аналитические расчёты
многоступенчатые преобразования данных
работа с "грязными" данными
отладка логики
Важный нюанс
Временные таблицы - это не единственный инструмент.
Есть ещё:
CTE (WITH)
подзапросы
Но:
👉 CTE - это "логика в одном запросе"
👉 временные таблицы - это "разбивка на реальные шаги"
Иногда CTE читается тяжело.
А временные таблицы дают ощущение "пайплайна".
Где часто ошибаются
создают временные таблицы без необходимости
забывают, что они завязаны на сессию
используют их там, где проще CTE
То есть это инструмент - не серебряная пуля.
Самая простая мысль
Временная таблица - это способ остановиться посередине запроса и зафиксировать результат
И иногда именно это спасает:
читаемость
производительность
и твои нервы
В канале Аналитика FM (клик :-) )я рассказываю про продуктовые метрики в разных бизнесах. В чем особенности и нюансы. Серия постов про средний чек уже готова.
Подписывайся, если интересно интересно разбираться в особенностях работы аналитика.
Показать полностью
1
Изменения во времени
Представь обычную ситуацию:
Есть клиент, сегодня он живет в Москве
В таблице это выглядит так:
| user_id | city |
| ----------- | ------------- |
| 1 | Москва |
Проходит время, он переезжает в Санкт-Петербург
Ты обновляешь данные
| user_id | city |
| ----------- | ---------------------------- |
| 1 | Санкт-Петербург|
И вроде всё ок.
Но потом приходит задача:
👉 А посчитай выручку по городам за прошлый год
И тут начинается самое интересное.
А в моем канале Аналитика FM выпуски про расчет Cohort Retention в разных бизнесах.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!
Если ты просто возьмешь текущие данные, то все заказы пользователя "уедут " в Санкт-Петербург. Даже те, которые он делал, когда жил в Москве.
И аналитика начнёт врать.
Не потому что ты ошибся.
А потому что данные потеряли свою историю.
Вот здесь и появляется SCD
SCD (Slowly Changing Dimension) - это способ хранить изменения так,
чтобы ты мог ответить не только на вопрос:
👉 Как сейчас?
но и на более важный:
👉 Как было в момент события?
Как будет выглядеть: вместо одной строки в таблице будет:
| user_id | city | start_date | end_date |
| ------------ | --------------------------- | ----------------- | -------------------- |
| 1 | Москва | 2024-01-01 | 2025-01-01 |
| 1 | Санкт-Петербург| 2025-01-01 | NULL |
Теперь у нас есть не просто данные,
а контекст во времени.
Почему это важно
Потому что почти всё в бизнесе меняется:
клиенты переходят между сегментами
продукты меняют категории
условия договоров обновляются
статусы живут своей жизнью
И если ты смотришь только на "сейчас" - ты теряешь половину смысла.
Самый важный момент
SCD - это не про таблицы.
Это про мышление.
Когда ты начинаешь задавать вопросы так:
А на момент события это было актуально?
А не поменялось ли это потом?
- ты переходишь на другой уровень понимания данных.
Где чаще всего ошибаются
Берут текущие данные
и применяют их к прошлым событиям.
И получается:
красивые отчёты
аккуратные цифры
полностью неверные выводы
Простая мысль, которую стоит запомнить
Данные без времени - это половина правды
SCD - это как раз про то, чтобы эту вторую половину не потерять.
И если тебе интересно разбираться в таких вещах глубже -
не просто "как написать SELECT", а как думать про данные,
в Аналитика FM я как раз про это и пишу.
Показать полностью