Анализ и проектирование систем *

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

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

Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».

Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.

В результате — знания есть, но целостной картины видения продукта нет.

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

В этой части цикла мы поговорим о центральном элементе GraphQL — схеме. Именно она является точкой соприкосновения клиента и сервера. И если нет схемы — то нет и API.

Привет, всем!

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

Разработка браузерного расширения началась с простой идеи: упростить поиск по закладкам и открытым вкладкам, а также попробовать свои силы в создании проекта с элементами монетизации. В этой статье я расскажу, как за две недели прошёл путь от прототипа до публикации в Chrome Web Store и Firefox Add-ons, какие технологии использовал и с какими трудностями столкнулся. Надеюсь, мой опыт вдохновит других разработчиков попробовать свои силы в создании подобных проектов. Полный код проекта доступен на GitHub.

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

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

— правильно выстроенную иерархию данных;

— методы консистентного предсказания абсолютных и относительных метрик;

— частые проблемы моделей и то, как мы их фиксили;

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

Привет! Это команда курса «Python для анализа данных». Собрали для вас подборку бесплатных ресурсов для изучения Python с нуля. Здесь вы найдёте как интерактивные курсы с практическими заданиями, так и теоретические материалы с подробными объяснениями.

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

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

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

Меня зовут Вячеслав Кудряшов, я исполнительный директор Mission Control Center в Сбере. Предлагаю порассуждать о том, что такое «неподходящий момент» и как бороться со сбоями в этот период.

Привет, Хабр! Меня зовут Маша, я бренд-аналитик, провожу разные исследования, а в перерывах пишу на Хабр. Коллеги из команды спецпроектов попросили меня протестировать на моих реальных задачах MWS Tables и сравнить со своими привычными сервисами. Я проверила его для проведения опросов, обработки данных и отслеживания задач на канбан-доске — и готова поделиться впечатлениями.

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

Зачем существуют профессиональные конференции? Зачем одни подают заявки на доклады, стремятся поделиться практическим опытом или личным мнением относительно того или иного вопроса? Зачем другие платят не маленькие деньги, покупают билеты, слушают, о чём говорят первые?

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

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

Идея написать статью пришла ко мне, когда я читала книгу «Цветы для Элджернона». Кто не знаком с произведением, советую его прочитать: это глубокий и пронзительный психологический роман, в котором мужчина с нарушениями интеллектуального развития по имени Чарли стал гением благодаря научному эксперименту. И хотя цель была высокой и благородной, а результат — достойным, герой  доставил достаточно хлопот ученым на своем пике развития интеллекта. Что-то все-таки пошло не так, и постепенно Чарли потерял все знания, которые ему открылись. В какой-то момент чтения я подумала: а ведь похожим образом ведут себя требования. Они сначала простые, понятные. Потом бац! Они начинают умнеть, эволюционировать, требуют больше ресурсов и в конечном счете создают хаос и порой даже рушат текущие процессы.

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

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

Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:

Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?

Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).

Эта статья является дополненной адаптацией статьи профессора Леонардо Карвало. Сначала описывается структура ОБЛАСТЕЙ (выделены разным цветом), затем перечисляются блоки (пронумерованы). В каждом блоке есть: описание в чем его задумка и примеры вопросов, советы, пример заполнения.

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

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

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

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

На дворе лето, середина года уже позади. Самое время оглянуться назад и критически взглянуть на прогнозы, которые делались в декабре-январе. Итак, давайте посмотрим, что обещали нам по части BPM в 2025 году и что из этого сбылось, а что осталось лишь в фантазиях авторов этих прогнозов. В принципе все писали более-менее одно и то же, поэтому для разбора взял один рандомный прогноз «BPM Solution for 2025: Trends and Updates».