#системныйанализ

[ignik-universe]

Эмерджентность: когда целое больше, чем сумма частей

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

🚀 В технике: Искусственный интеллект – не просто алгоритмы, а сложная система, где взаимодействие нейронных сетей даёт неожиданные возможности, которых не было в базовых компонентах.

🏢 В бизнесе: Стартапы с сильной командой способны делать невероятные вещи, даже если каждый сотрудник по отдельности не гений. Синергия = эмерджентность в действии!

🌍 В жизни: Человеческое общество – классический пример эмерджентности. Экономика, культура, нау��а рождаются из взаимодействия людей, но их нельзя свести к сумме отдельных вкладов.

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

💡 Как вы сталкивались с эмерджентностью в своей работе и жизни?

[bigdataschool-moscow]

Как не превратить Scrum в драку: анализ требований и project management по Agile

В контексте темы бережливого производства в ИТ, сегодня мы расскажем про анализ требований к разработке ПО в условиях Agile-подходов к организации работы и соответствия жестким рамкам отечественных ГОСТов и зарубежных стандартов. Читайте в нашей статье, что говорит BABOK по этому поводу и когда нужно запускать процесс создания программной документации, чтобы потом не было мучительно больно.

Лишнее для Lean или в чем ценность поддерживающих процессов?

На первый взгляд с позиции бережливого производства (Lean) разработка требований не добавляет ценности конечному продукту, а является поддерживающим процессом для основной деятельности (собственно разработки ПО). Например, в этой статье мы рассматривали выявление требований в качестве иллюстративного примера для функционально-стоимостного анализа, а здесь – для объяснения метода Value Stream Mapping (картирование потоков создания ценностей). Напомним, одна из 4-х основных идей Agile Manifesto гласит, что работающий продукт важнее исчерпывающей документации [1]. Поэтому у команды проекта, работающей по Agile (Scrum, Kanban, XP и прочие гибкие методологии) может возникнуть соблазн исключить или максимально сократить этот этап. Однако, стоимость ошибки многократно возрастает по мере развития проекта [2]. Поэтому отказываться от анализа требований нельзя. Впрочем, на самом деле Agile и не призывает к столь радикальным решениям, предлагая методологию гибкого моделирования – Agile Modelling. Она предполагает непрерывное документирование параллельно с выполнением остальных задач гибкой разработки ПО (непосредственно кодирования, тестирования и развертывания). При этом требования определяются в форме исполняемых «пользовательских тестов» вместо статической документации [3]. Об этом же говорит профессиональный стандарт бизнес-аналитика, руководство BABOK, включив Agile в набор 5 ключевых перспектив. В главе, посвященной анализу в условиях гибкого подхода, BABOK подчеркивает, что аналитик продолжает выполнять свои прямые обязанности по взаимодействию со стейкхолдерами, чтобы выявить бизнес-потребности и определить, как создаваемый продукт совпадает с задачами организации, помогая достичь поставленные цели. При этом в зависимости от видения продукта генерируется бэклог (backlog) – приоритетный список рабочих задач, которые необходимо выполнить в первую очередь. В соответствии с Lean-концепцией, приоритезация пунктов бэклога основана на принципе максимальной ценности для потребителя [4]. Однако, несмотря на позиционирование в качестве профессионального руководства, BABOK – это свод знаний, а не жесткий шаблон готовых решений с пошаговым описанием способа выполнения работ. В отличие от ГОСТов и зарубежных стандартов, он не регламентирует процедур создания программной документации, в частности, технического задания (ТЗ). А на постсоветском пространстве часто именно ТЗ до сих пор считается основным результатом деятельности аналитика, что не совсем коррелирует с принципами Agile и реальностью современных проектов. Тем не менее, на самом деле работа по ГОСТам абсолютно не противоречит Agile, о чем и мы поговорим далее.

Стандарты разработки требований и Agile: комбо или противостояние?

Из отечественных стандартов требования к проектируемой системе в форме ТЗ регламентируют ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению». Они оба содержат по 9 разделов с похожим назначением, но отличаются по специфике применения. ГОСТ 34.602-89 описывает ТЗ на автоматизированную систему, включая программное и аппаратное обеспечение, пользователей и автоматизируемые процессы. А ГОСТ 19.201-78 предназначен именно для ПО. Некоторые ИТ-специалисты эти ГОСТы устаревшими, однако большинство государственных учреждений, выступая в роли Заказчика, требуют соблюдение этих стандартов. Кроме того, хоть данные документы и не являются непосредственным исходником для программистов, на основе которых они создают программный код, данные стандарты позволяют достаточно подробно описать осно��ные бизнес-потребности и ключевое назначение будущего продукта [5]. Зарубежный стандарт ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering» предполагает более детальное описание требований, чем вышеупомянутые отечественные ГОСТы. Однако, если разрабатывать ТЗ на будущую систему в соответствии с этим документом, это потребует слишком много ресурсов и задержит создание продукт, что не соответствует принципам Agile. Поэтому, с учетом возможности изменений на любых стадиях проекта, целесообразна итерационная проработка требований по мере его развития. Таким образом, в Agile-проекте не стоит подробно документировать все требования в самом начале. Сперва следует определить бизнес-потребности, затем выявить высокоуровневые требования и изложить их в виде пользовательских историй (user story). Именно ими наполняется бэклог проекта, после чего начинается приоритизация задач. Данный цикл повторяется на каждый итерации по мере развития проекта. При этом следует как можно раньше определить нефункциональные требования, чтобы спроектировать архитектуру системы для обеспечения производительности, удобства использования, доступности и другие цели по качеству. Напомним, пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей [6]. Подробнее про формулирование требований в конструкциях языка Gherkin мы рассказывали здесь. Работа с требованиями по Agile Реализация каждой пользовательской истории отслеживается с помощью статуса входящих в нее задач по принципу канбан-доски, например, так [6]: •         в бэклоге – история пока не назначена на конкретную итерацию; •         определена – подробности истории обсуждены и поняты, приемочные тесты написаны; •         разработка – история в процессе р��ализации; •         завершена – история полностью реализована; •         принята – пройдены приемочные тесты; •         заблокирована – разработчик не может продолжить разработку, пока не будут разрешены другие вопросы.   �� практической точки зрения более ценны требования в виде UML-диаграмм и задач в Jira (или аналогичном системе), чем набор статических текстовых документов в строгом соответствии с ГОСТами или зарубежными стандартами. Однако, последние являются обязательными при сдаче готового решения Заказчику. Поэтому разработка таких документов тоже является неотъемлемой частью процесса создания готового продукта. При этом, разработка программной документации по ГОСТам выполняется параллельно с кодированием, тестированием и развертыванием, углубляясь в детали с каждым итерационным циклом. В любом случае, прежде всего выявляются основные бизнес-потребности, определяются ключевые высокоуровневые требования и формализуются в виде пользовательских историй. Так формируется Устав проекта (project scope) и бэклог продукта, на основании чего и планируется дальнейшая работа. Поэтому строгая регламентация требований и другой программной документации по отечественным ГОСТам и зарубежным стандартам совсем не противоречит принципам Agile, а органично дополняет их. Таким образом, адаптивность гибких подходов сдерживается четкостью формальных рамок, объединяя преимущества обоих сторон. Другие особенности применения Agile-принципов к ИТ-процессам, примерам цифровизации бизнеса и практическим кейсам аналитики больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве: Аналитика больших данных для руководителей Анализ и оптимизация бизнес-процессов

 Смотреть расписание занятий

 Зарегистрироваться на курс Источники 1.       https://ru.wikipedia.org/wiki/Гибкая_методология_разработки 2.       http://okiseleva.blogspot.com/2018/03/blog-post_59.html 3.       https://en.wikipedia.org/w/index.php?title=Agile_Modeling 4.       https://analytics.infozone.pro/babok-3-chapter-11-agile-perspective/ 5.       https://habr.com/ru/post/328822/ 6.       https://analytics.infozone.pro/requirements-analysis/agile-software-development/ Read the full article

[ignik-universe]

Примеры систем. Удивительное родство несравнимого.

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

📌 Почему? Потому что оба примера относятся к элементарным закрытым системам со статической структурой: – У них ограниченный набор элементов – Связи между элементами закономерны и не изменяются во времени – Взаимодействия не приводят к качественным изменениям структуры

🌀 А теперь — неожиданный дуэт: огромный завод и ядро атома — тоже одноклассники! Они входят в класс динамически изменяющихся, открытых систем, у которых: – Большое количество элементов – Связи между ними нестабильны и изменяются во времени – Взаимодействие может вести к качественным изменениям всей системы

💡 Масштаб, материальность, назначение — всё это вторично. Главное — тип структуры, характер связей и реакция системы на внутренние и внешние воздействия.

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

#системныйанализ #структура #игник #инженерныйподход

[ignik-universe]

Стандартизация

📊 Стандартизация — ключ к зрелости и цифровой трансформации! 🔧

Думаете, стандартизация — это скучно и про бумажки? Нет! Это фундамент, на котором строится успех современного предприятия. 💼 Грамотно организованная стандартизация процессов и продукции — признак зрелости компании и её готовности к цифровой трансформации. 🚀

🌟 Почему стандартизация важна?

1️⃣ Упрощает процессы — единые правила сокращают хаос и ускоряют работу. 

2️⃣ Повышает качество — стандарты продукции минимизируют ошибки и брак. 

3️⃣ Готовит к цифре — без стандартов автоматизация и новые технологии просто не взлетят.

💡 Пример: Компания Y внедрила стандарт на описание бизнес-процессов. Результат? Время на обучение новых сотрудников сократилось на 30%, а внедрение ERP-системы прошло без срывов. 📈

🔥 Как начать?

Проведите аудит текущих процессов.

Определите, что можно унифицировать (от шаблонов документов до workflows).

Вовлеките команду — стандарты работают, только если их принимают.

Стандартизация — это не ограничение, а свобода для масштабирования и инноваций! 💻 Готовы ли вы привести свои процессы к единому знаменателю? Делитесь в комментариях, какие стандарты уже используете! 👇

#БизнесАнализ #СистемныйАнализ #Стандартизация #ЦифроваяТрансформация #игник

[ignik-universe]

Исследование операций 

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

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

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

🎯 Цель — не просто найти решение, а оптимизировать выбор: ресурсов, маршрутов, действий, стратегий.

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

#игник #системныйанализ

[ignik-universe]

🧠 10 принципов системного анализа: мышление, которое меняет всё

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

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

🔗 Принцип единства Смотрите на систему одновременно как на целое и как на совокупность элементов. Целое — больше суммы частей.

🌍 Принцип связности Нет элемента вне контекста. Любую часть нужно понимать во взаимосвязи с окружением.

🧩 Принцип модульного построения Делите сложное на части. Модули — удобный способ понимать �� управлять.

⚙️ Принцип функциональности Сначала — функция, потом структура. Система — это то, что она делает, а не только как она устроена.

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

🏛 Принцип децентрализации Сильная система умеет сочетать централизацию и свободу действий. Это и есть "децентрализованный централизм".

🎲 Принцип неопределённости Не всё можно предусмотреть. Но можно встроить гибкость и устойчивость к случайностям.

📐 Принцип иерархии Ищите уровни. Не всё важно одинаково. Ранжируйте элементы — и принимайте решения с приоритетами.

📌 Эти принципы — не только для аналитиков. Они для менеджеров, предпринимателей, преподавателей, родителей и стратегов. Применяйте их — в проектах, в командах, в управлении, в жизни.

Системное мышление — не только навык. Это новая грамотность.

#СистемныйАнализ #СистемноеМышление #БизнесАнализ #ПринципыУправления #игник #МышлениеXXIвека

[ignik-universe]

🔍 Системный анализ — профессия, которая незаметно стала частью всех профессий.

Сегодня системным анализом занимаются все: — разработчики нейросетей и создатели ChatGPT 🤖 — архитекторы бизнес-моделей и процессов 💼 — инженеры, логисты, проектировщики 🏗 — и даже… сантехники, когда разбираются в структуре и функциях трубопровода! 🛠

🧠 Но главное в системном анализе — не инструменты, а мышление.

Это не просто про "разобрать систему на части", а про понимание её сути: — Как устроена структура? — Какие функции она выполняет? — Что она должна достичь? — Как она вписана в более широкую систему знаний и целей?

💡 Именно поэтому системный аналитик — это не просто инженер или бизнес-аналитик. Это философ, исследующий диалектику структуры и функций. ⠀ 🎯 Чтобы построить эффективную систему — техническую, бизнесовую или даже социальную — нужно мыслить на уровне целей, контекстов и смыслов.

📌 Системный анализ — это язык, на котором разговаривает сложность. Освоив его, ты начинаешь понимать не только системы… но и саму реальность.

#СистемныйАнализ #БизнесАнализ #СистемноеМышление #игник  #ИнженерияЗнаний #АналитикаБудущего

[ignik-universe]

Закономерности и структуры систем

[bigdataschool-moscow]

Agile и бережливое производство: что общего между Lean и DevOps

Чтобы сделать курс Аналитика больших данных для руководителей еще более интересным, мы продолжаем включать в него темы про методы производственной оптимизации. Сегодня рассмотрим, что такое бережливое производство (Lean) и почему Agile вообще и DevOps в частности активно используют принципы этой концепции. Также читайте в нашей статье, чем Lean отличается от системы менеджмента качества (СМК) и методики 6 сигм.

Что такое Lean: бережливое производство для чайников

Прежде всего, сделаем краткий ликбез по теме бережливого производства (Lean). Эта концепция управления предприятием предполагает непрерывное устранение всех видов потерь с целью максимальной оптимизации бизнеса для наилучшего удовлетворения потребителя. Она основана на производственной системе японской компании Toyota, благодаря которой автоконцерн вышел из послевоенного кризиса и устал успешной организацией в мировом масштабе. Идеи бережливого производства отражены во множестве современных методов управления качеством, наиболее популярными из которых считаются следующие [1]: ·       вытягивание, когда объёмы продукции и сроки её изготовления на каждом производственном этапе определяются исключительно потребностями заказчика, а не заранее разработанным и спущенным сверху планом; ·       точно вовремя (Just in Time), когда движение материальных потоков организовано так, что все материалы и компоненты, необходимые для реализации готовой продукции, поступают в необходимом количестве, в нужное место и ��очно к назначенному сроку, не занимая место на складах; ·       канбан – визуализация состояния рабочих задач для повышения прозрачности процессов и равномерного распределения нагрузки между их участниками; ·       быстрая переналадка оборудования (SMED, Single-Minute Exchange of Dies), когда его ремонт и переоснастка выполняются с высокой скоростью по заранее определенным схемам; ·       картирование потоков создания ценностей (VSM, Value Stream Mapping) для визуализации процессов создания продуктов, представляющих ценность для конечного потребителя с целью выявления лишних операций и их устранения. Пример такой VSM-карты мы рассматривали в этой статье. ·       автономизация оборудования, когда оно способно самостоятельно обнаружить проблемы, диагностировать и устранять собственные неисправности, сразу останавливая производственный процесс и сигнализируя об этом при выявлении дефектов в качестве продукции или задержек в работе; ·       система 5S для организации и рационализации рабочего места или пространства, суть которой заключается в сортировке, соблюдении порядка, содержании в чистоте, стандартизации и совершенствовании установленных правил, процедур и технологических операций; ·       защита от дурака, когда конструктивные или другие технологические особенности реализации решения не позволяют использовать его неверно.   Иногда к методам бережливого производства еще относят концепцию 6 сигм, основанную на статистических методах управления качеством для измерения отклонений реальной продукции от заданного эталона и сокращения дефектов. Однако, при общих целях повышения эффективности рабочих процессов и итоговых результатов, подход 6 сигм отличается от принципов Lean, а потому не входит в понятие бережливого производства. Тем не менее, на практике возможно совместное применение этих концепций для комплексного улучшения производственной деятельности и повышения удовлетворенности клиентов [2]. Не случайно профессиональный стандарт бизнес-аналитика, руководство BABOK, включило методы Lean и 6 сигма в наиболее часто используемые техники процессного анализа.

СМК, DevOps и Lean: сходства и отличия

В отличие от типовой системы менеджмента качества, которая декларативно описывает, что нужно делать, но не говорит, каким образом, принципы бережливого производства подробно рассказывают, как снизить потери или вообще избавиться от них [3]. В частности, метод картирования потоков создание ценностей пошагово регламентирует, как создать VSM, а система 5S вообще представляет собой простой и дешевый способ рациональной организации рабочего пространства. Также важным свойством Lean-концепции является универсальность ее методов, которые можно применять не только для эффективного управления заводом или другим промышленным предприятием. Эти подходы отлично подходят и к области ИТ. К примеру, из 12 принципов Манифеста Agile почти половина полностью повторяют идеи Lean [3]. Особенно четко это прослеживается в философии DevOps, направленной на ускорение процессов разработки и эксплуатации программного обеспечения с помощью средств автоматизации повторяемых процессов и управления инфраструктурой как кодом [4]. Вообще тему испо��ьзования принципов Lean в разработке программного обеспечения впервые раскрыли Мэри и Том Поппендики, опубликовав книгу «Lean Software Development» в 2003 году. Распространению их идей поспособствовала популяризация Agile-подходов к организации процессов в ИТ и других сферах деятельности [5]. В следующей статье мы рассмотрим, как некоторые методы бережливого производства реализованы в технологиях Big Data. В заключение стоит отметить, что, как и любые управленческие подходы, Lean – это прежде всего не про технологии и инструменты, а про изменение бизнес-процессов и человеческого мышления. Именно это объединяет бережливое производство и цифровизацию.  От философии к практикам: как связаны Lean и Agile Больше подробностей про методы бережливого производства и их применение в цифровизации бизнеса и аналитике больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве: Аналитика больших данных для руководителей Анализ и оптимизация бизнес-процессов

 Смотреть расписание занятий

 Зарегистрироваться на курс Источники 1.       https://ru.wikipedia.org/wiki/Бережливое_производство 2.       https://ru.wikipedia.org/wiki/Шесть_сигм 3.       https://probusiness.io/management/3811-lean-eto-ne-tolko-pro-proizvodstvo-komu-i-dlya-chego-nuzhna-eta-metodologiya.html 4.       https://www.litres.ru/oleg-skrynnik/devops-dlya-it-menedzherov-48411311/ 5.       https://ru.wikipedia.org/wiki/Бережливая_разработка_программного_обеспечения Read the full article

[bigdataschool-moscow]

Сколько стоит цифровизация: что такое ФСА и зачем это нужно в Big Data

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

Что такое ФСА и зачем это нужно

Определить себестоимость и другие непосредственные показатели бизнес-процессов можно с помощью метода функционально-стоимостного анализа (ФСА). Иногда его также называют ABC-анализ (Activity Based Costing), но это не совсем верно по следующим причинам [1]: ·       так называемый ABC-анализ используется для классификации корпоративных ресурсов по степени важности, например, ранжирование товарных запасов или поставщиков в розничной торговле [2]; ·       Activity-based costing - расчёт себестоимости по видам деятельности, который переводит накладные расходы в прямые затраты. Эта модель описания затрат идентифицирует работы и назначает затраты каждой отдельно взятой работе в соответствии с ее настоящей стоимостью [3]. Классический ФСА по-английски называют Value Engineering, Value Management или Value Analysis. Задачей этого метода является достижение наивысших потребительских свойств продукции при одновременном снижении всех видов производственных затрат. Для этого процесс представляют в виде набора взаимосвязанных функций, каждая из которых продолжается определенное время и требует вложения ресурсов (человеческих или материальных) [1]. Рассмотрим пример из профессионального руководства по бизнес-анализу BABOK о выявлении требований к новому продукту. Для простоты понимания представим процесс проектирования новой Big Data системы следующим образом: ·       определение бизнес-потребностей и выявление требований к решению, включая взаимодействие со стейкхолдерами, анализ текущих процессов, информационных систем, потоков данных, документации и архитектуры предприятия – выполняется бизнес-аналитиком за 160 часов с оплатой труда 50$ в час; ·       разработка технического задания на новую систему, что делает тот же аналитик за 40 часов; ·       создание подробного технического проекта будущей системы с описанием всех функциональных и нефункциональных требований, вариантов и сценариев использования, а также архитектуры решения с учетом корпоративного ИТ-ландшафта – выполняется аналитиком за 160 рабочих часов и требует 40-часового участия архитектора Big Data с почасовой ставкой 100$. Поскольку цель рассматрива��мого примера – объяснить сам принцип ФСА, для простоты вычислений не будем включать в расчеты затраты на амортизацию материальных ресурсов (помещений, компьютеров и программного обеспечения). Таким образом, непосредственная себестоимость процесса, определенная на основе расходов по оплате труда выполняющих его специалистов, составит 160*50+40*50+160*50+40*100=22000$. Пример расчета себестоимости процесса по методу ФСА

Зачем цифровизация использует ФСА: Big Data и Lean

Итак, суть ФСА в поэлементной отработке конструкции, разделяя элементы по принципу функционирования на основные и вспомогательные. Обычно этот подход применяется в технико-экономических задачах, однако некоторые его концепции можно перенести и область ИТ. Например, пусть суточная стоимость пользования облачным кластером, где развернуты Big Data приложения Apache Spark, Kafka и Hadoop оценивается в 2,5 доллара. Если за это время на нем выполнится 25 тысяч рабочих задач, то стоимость каждой задачи (источника издержек) будет составлять составит 0,01 цент. При уменьшении количества задач стоимость источника издержек повысится, а при уменьшении – наоборот, кластер будет дешевле. Однако, чрезмерное повышение производительности чревато проблемами с доступностью данных, о чем мы рассказывали на примере работы Apache Kafka в высоконагруженных системах. Вообще в ФСА возможны 2 типа источников издержек [4]: ·       по функциям (activity drivers), которые показывают, как поведение объекта затрат влияет на уровни детализации функций. ·       по ресурсам (resource drivers), которые описывают, каким образом уровни активности функций влияют на потребление ресурсов. В рассмотренном кейсе с кластером, где развернуты Big Data приложения на базе Apache Spark, Kafka и Hadoop, стоимость задачи в зависимости от их количества – это пример источника издержек по ресурсам, т.к. загрузка кластера является главным фактором расчета. А сам объект затрат – это облачный кластер, используемый для автоматизации конкретных бизнес-процессов.   Расчет затрат по методу ФСА в ИТ С учетом того, что цифровизация ориентирована на комплексную оптимизацию деятельности, в т.ч. финансовой сферы, с помощью ИТ, ФСА – это отличный инструмент количественной оценки расходов. Поэтому знание данного метода будет полезно руководителям проектов цифровой трансформации. Несмотря на то, что ФСА напрямую не относится к методам бережливого производства (Lean), между ними очень много общего. В частности, понятие ценности для потребителя, которую нужно максимизировать путем сокращения затрат [1]. Именно эта идея устранения потерь – действий, которые не производят ценности для конечного потребителя, лежит в ��снове философии менеджмента качества, впервые в промышленном масштабе внедренной в японской автомобилестроительной компании «Тойота». Благодаря системе менеджмента качества, основанной на принципах Lean («точно в срок», канбан, защита от ошибок) и интеллектуальной автоматизации производства, предприятие успешно вышло из послевоенного кризиса и стало преуспевающим международным автогигантом [5]. В следующей статье мы рассмотрим подробнее один из инструментов Lean – картирование потоков создания ценности, который продолжает идеи метода ФСА по количественной оценке каждой функции бизнес-процесса и позволяет оптимизировать деятельность с помощью анализа результатов. Больше практических кейсов из прикладного системного анализа, цифровизации бизнеса и аналитики больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве: Аналитика больших данных для руководителей Анализ и оптимизация бизнес-процессов

 Смотреть расписание занятий

 Зарегистрироваться на курс Источники 1.       https://ru.wikipedia.org/wiki/Функционально-стоимостный_анализ 2.       https://ru.wikipedia.org/wiki/ABC-анализ 3.       https://ru.wikipedia.org/wiki/Activity_Based_Costing 4.       https://www.cfin.ru/management/controlling/iso_abc.shtml 5.       https://ru.wikipedia.org/wiki/Производственная_система_«Тойоты»   Read the full article

[bigdataschool-moscow]

Что такое BABOK и при чем здесь Big Data

Чтобы дополнить курс  Аналитика больших данных для руководителей современными трендами в области системного анализа, сегодня мы расскажем, что такое BABOK, для чего ��ужен этот профессиональный стандарт бизнес-аналитика и как его содержание коррелирует с технологиями Big Data.

Что такое BABOK и зачем он нужен

Начнем с определения: BABOK – это аббревиатура от Business Analysis Body of Knowledge, свод знаний по бизнес-аналитике от Международного института бизнес-анализа IIBA (International Institute of Business Analysis), который базируется в Канаде [1]. По сути, BABOK представляет собой профессиональный стандарт бизнес-аналитика, описывая необходимые для этой деятельности области знаний, базовые компетенции, методы, техники и практики, а также системные подходы к бизнес-анализу с практической точки зрения. Впервые этот свод знаний был выпущен в 2005 году, а последней версией считается издание 3.0, представленное в апреле 2015 года [2]. Основной целью BABOK считается определение профессии бизнес-аналитика с помощью согласованной терминологии и решаемых на практике задач [3]. Несмотря на то, что данный свод знаний принято называть руководством, он представляет собой скорее фреймворк профессиональной деятельности бизнес-аналитика, а не пошаговый учебник по конкретной технологии или набору методик. Более того, данный стандарт ориентирован на специалистов с опытом практической работы в системном анализе и бизнес-аналитике, поскольку содержит упоминание о множестве технологий и особенностях их применения, но не раскрывает основ. Таким образом, BABOK нужен, прежде всего, самим системным и бизнес-аналитикам, а также преподавателям и специалистам, которые проектируют учебные курсы и программы обучения по бизнес-аналитике и системному анализу [3]. Для руководителя и HR-менеджера BABOK – это отличный профессиональный маркер, который отмечает состоявшегося аналитика. Для этого IIBA осуществляет сертификацию по данному стандарту через сдачу экзаменов в виде онлайн-тестирования. В частности, возможны следующие уровни сертификации по BABOK [4]: ·       ECBA (Entry Certificate in Business Analysis) – начальный уровень базовых компетенций бизнес-аналитика, необходимо освоить 21 час профессионального развития (тренинги, специальные курсы по критериям IIBA), нет требований к практическому опыту [5]. Сертификат бессрочный. ·       CCBA (Certification of Capability in Business Analysis) – продвинутый уровень компетенций бизнес-аналитика, необходимо освоить 21 час профессионального развития за последние 4 года и иметь минимум 3750 часов (2-3 года) практической работы бизнес-аналитиком за последние 7 лет [6]. Срок действия сертификата - 3 года, затем ресертификация в виде повторного экзамена. ·       CBAP (Certified Business Analysis Professional) – экспертный уровень компетенций бизнес-аналитика, необходимо освоить 35 часов профессионального развития за последние 4 года и иметь минимум 7500 часов (около 5 лет) практической работы бизнес-аналитиком за последние 10 лет [7]. Срок действия сертификата - 3 года, затем ресертификация в виде повторного экзамена.

Сертификация от IIBA по BABOK: от новичка до эксперта

Что написано в Business Analysis Body of Knowledge: краткое содержание

Вообще BABOK 3.0 состоит из 11 глав и 4-х приложений, суть которых состоит в следующем [1]: ·       в главах 1 и 2 изложены основные понятия бизнес-анализа, определение работы бизнес-аналитика, структура самого стандарта, базовые термины и ключевые концепции; ·       главы 3-8 описывают области знаний бизнес-анализа; ·       в главе 9 приведены основные профессиональные компетенции бизнес-аналитика, а в главе 10 –техники, наиболее часто используемые для решения прикладных задач; ·       глава 11 рассказывает о перспективах, в рамках которых работает бизнес-аналитик; ·       наконец, в приложениях приведен глоссарий терминов, картирование техник по задачам, список экспертов-разработчиков и отличия BABOK v3 от предыдущей версии.   В этой статье мы лишь частично раскроем ключевое содержание стандарта, оставив специфику профессиональных техник и компетенций для следующих публикаций. Важно, что в бизнес-анализе BABOK выделяет 6 областей знаний [1]: Планирование и мониторинг бизнес-анализа (Business Analysis Planning and Monitoring) – задачи, необходимые для организации деятельности бизнес-аналитиков и координации их усилий;  Обследование и взаимодействие (Elicitation and Collaboration) – задачи по подготовке и проведению обследования, а также утверждению результатов, в т.ч. взаимодействие с заинтересованными лицами (стейкхолдерами);   Управление жизненным циклом требований (Requirements Life Cycle Management) – задачи по управлению и поддержке требований, а также технических проектов (дизайнов) от их возникновения до устаревания;   Стратегический анализ (Strategy Analysis) – задачи по идентификации бизнес-потребностей, определению способов их удовлетворения и согласования стратегических изменений внутри предприятия;   Анализ требований и определение дизайнов (Requirements Analysis and Design Definition) - задачи по организации требований и проектов, их определению и моделированию, проверке и подтверждению, разработке вариантов решения и оценки их потенциальной ценности, которая может быть достигнута.   Оценка решений (Solution Evaluation) -  задачи по оценке производительности и ценности решений, разработка рекомендаций по их улучшению.    Все эти работы бизнес-аналитик выполняет в рамках 5 перспектив [1]: методологии гибкой разработки (Agile);  интеллектуальный анализ данных для принятия бизнес-решений (Business Intelligence); информационные технологии (Information Technology);  бизнес-архитектура (Business Architecture);  управление бизнес-процессами (Business Process Management).   При этом бизнес-аналитик активно пользуется различными техниками системного анализа, управления данными, маркетинговых исследований и проектного менеджмента: структурные диаграммы для формализации процессов, стратегические карты, SWOT-ква��ранты, методы приоритезации и другие практические инструменты.

6 областей знаний BABOK и их основные задачи

Как цифровизация и Big Data могут использовать Бабок

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

Взаимосвязи между областями знаний BABOK Подробнее о том, как применять BABOK в проектах цифровой трансформации и аналитике больших данных, вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве: Аналитика больших данных для руководителей Анализ и оптимизация бизнес-процессов

 Смотреть расписание занятий

 Зарегистрироваться на курс Источники 1. https://www.iiba.org/standards-and-resources/babok/ 2. https://en.wikipedia.org/wiki/A_Guide_to_the_Business_Analysis_Body_of_Knowledge 3. https://hsbi.hse.ru/articles/babok-guide-business-analysis-body-of-knowledge/ 4. https://www.iiba.org/certification/iiba-certifications/ 5. https://www.iiba.org/certification/iiba-certifications/ecba/ 6. https://www.iiba.org/certification/iiba-certifications/ccba/ 7. https://www.iiba.org/certification/iiba-certifications/cbap/ Read the full article

[bigdataschool-moscow]

Определяем, что важнее: методы расстановки приоритетов в Big Data и цифровизации

Сегодня мы поговорим про одно из ключевых понятий управления проектами и бизнес-анализа: что такое приоритизация, почему это важно в цифровизации и внедрении технологий больших данных (Big Data). Также рассмотрим основные методы и практические техники расстановки приоритетов, которые будут полезны каждому менеджеру (руководителю) и любому специалисту: аналитику, разработчику, инженеру и исследователю данных (Data Scientist).

Что такое приоритизация и зачем она нужна в Big Data и цифровизации

Начнем с определения, которое приводит BABOK, профессиональный стандарт бизнес-аналитика [1]: приоритизация – это процесс определения относительной важности объекта (информации, задачи, требования и пр.) на основе предварительной оценки его значения, рисков, сложности реализация или других четких критериев. В свою очередь, дисциплина управления (Project Management) проектами также рассматривает расстановку приоритетов в контексте портфельного управления, когда необходимо сформировать сбалансированный набор проектов предприятия в соответствии с его стратегией или финансовыми показателями. Также здесь учитывается период инвестирования (краткосрочный, средний, долгосрочный), прогнозы по рискам и доходности, и прочие организационно-технические аспектами [2]. Таким образом, можно выделить 2 уровня приоритизации: ·       стратегический, когда, например, директор по цифровизации или C-менеджер (CEO, CTO, CFO или другой руководитель высшего звена) формируют портфель проектов, определяя долгосрочную программу развития предприятия или управления изменениями в рамках цифровой трансформации; ·       тактический, когда бизнес-аналитик или менеджер проекта определяет важность отдельных задач или требований к проектируемому решению, например, системе прогнозирования потребительского спроса на основе технологий Big Data и Machine Learning. При том, что для каждого из этих уровней существуют свои методы расстановки приоритетов, они все направлены на определение важности каждого компонента. Это необходимо, чтобы в первую очередь инвестировать ресурсы (финансы, время и силы) именно в компоненты с наивысшим приоритетом. Для рассматриваемых нами примеров проекта цифровизации и внедрения Big Data продукта, стоит отталкиваться от главной цели проекта или основного назначения программного продукта, а также учитывать их эффективность [3].

Цифровизация: как рассчитать приоритет проекта

С точки зрения бизнес-аналитика в рамках управления требованиями к разработке программного обеспечения, приоритет – это атрибут (свойство) самого требования. Этот показатель определяет важность каждого требования относительно других. Например, к реализации какой функции стоит приступить прежде всего [4]. При этом BABOK выделяет 4 подхода к приоритизации [1]: ·       группировка – объединение требований в категории с высоким, средним и низким приоритетом; ·       ранжирование – составление упорядоченного списка, например, бэклог продукта (backlog) в Agile-подходе к разработке ПО; ·       ресурсные ограничения (время и/или бюджет) – расстановка приоритетов на основе объема работ, которую команда проекта способна выполнить за установленный период времени или за фиксированное количество денег (бюджет). Этот подход чаще всего используется, когда необходимо соблюсти четкий срок или для решений, которые улучшаются на регулярной и частой основе; ·       мнение заинтересованных лиц (стейкхолдеров) - установление консенсуса между заинтересованными сторонами относительно того, какие требования будут наиболее важными. На практике достичь такого согласия весьма проблематично [4].   В портфельном управлении чаще всего используются следующие подходы к приоритизации [2]: ·       весовое ранжирование – попарное сравнение проектов по одному критерию с помощью матрицы или таблица многокритериального сравнения; ·       скоринг – численные методы для объединения ранжированных компонентов внутри каждой категории; ·       экспертная оценка, основанная на анализе подобных случаев в данной предметной области. На практике для оценки важности проекта используются составные формулы для расчета приоритетов на основе классификационных признаков и мультипликаторов. Например, инновационность, рискованность, объем сторонних инвестиций, стратегическая важность, наличие подтвержденного финансирования и т.д. [5]. Также учитываются экономические показатели: чистая приведенная стоимость, срок окупаемости, внутренняя норма рентабельности и пр. [6]. Этапы портфельного управления: основы Project Management Разумеется, приоритизация в портфельном управлении и в анализе требований – это разные процессы. Обычно проекты цифровизации представляют собой можно комплексные организационно-технические мероприятия с большими бюджетами и различным содержанием. Поэтому наиболее эффективно сравнивать эти неоднородные компоненты по финансовым показателям. В свою очередь, отдельный проект по реализации или внедрению Big Data системы представляет собой набор взаимосвязанных задач, которые уже можно считать более-менее однородными по содержанию. Таким образом, приоретизировать их можно по степени влияния на общий результат. Для этого используются практические подходы (техники), самые популярные из которых мы рассмотрим далее.

5 популярных техник приоритизации

Итак, на практике наиболее часто используются следующие техники расстановки приоритетов среди однородных задач [7]: 1.       Impact/Effort [8] – как потраченные на реализацию задачи усилия соотносятся с нужным бизнесу результатом. В отличие от финансового показателя по возврату вложенных инвестиций (ROI), данный подход рассчитывается не в денежном выражении. Усилия можно оценивать в человеко-часах или пункты пользовательских историй b и вариантов использования (use case). Влияние может распределяться по шкале 1-5 или категориям высокое/среднее/низкое. 2.       Модель Кано, основанная на эмоциональном восприятии пользователем той или иной функциональности, например, [9]: o   Must Be — минимальные требования, при отсутствии которых пользователь не удовлетворен; o   Indifferent — требования с неоднозначной реакцией пользователей, которым, в основном, все равно, реализованы они или нет; o   Satisfiers (Performance) — функции, которые вызывают удовлетворенность, если они реализованы хорошо, или разочарование в противном случае. o   Exciters (Attractive) – дополнительные функции, которые повышают удовлетворенность пользователя, если они есть. Но их отсутствие не вызовет недовольства. В первую очередь следует реализовать задачи уровней Must be, затем - Satisfiers и только потом перейти к Exciters. Похожей на Kano техникой приоритизации считается метод MosCow, который делит требования на 4 категории: must, should, could, would [10]: o   Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе; o   Should – не самые важные требования, но они тоже должны быть выполнены после реализации «must»; o   Could – желательные требования, которые можно сделать, если останется время и будут ресурсы; o   Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта. 3.       Подход RICE, предложенный ИТ-корпорацией Intercom для оценки продуктовых изменений [11]: o   Reach (охват) - сколько пользователей охватит это нововведение; o   Impact (эффект) — насколько оно улучшит или ухудшит жизнь/работу пользователей; o   Confidence (уверенность) — степень уверенности в том, что вообще можем что-то улучшить; o   Effort (усилия) — сколько времени и других ресурсов понадобится, чтобы реализовать задуманное. 4.       Метод Карла Вигерса (Karl Wiegers), когда по шкале от 1 до 9 оцениваются польза (benefit), вред (penalty), расходы (cost) и риски (risk). Пользователи оценивают пользу от присутствия функциональной возможности (фичи) и вред от ее отсутствия. А разработчики оценивают стоимость реализации этой фичи и риск, связанный с ее разработкой. Полученные таким образом предварительные оценки подставляются в заранее составленную формулу и рассчитывается коэффициент приоритетности [12]. 5.       Feature Bucket (ведро фич) – подход от экс-СEO соцсети LinkedIn Адама Нэша (Adam Nash). Все фичи условно делятся на 3 категории [13]: o   Metric Movers – наиболее востребованные бизнесом функции и продуктовые метрики (охват, доход и пр.). o   Customer Requests – нужные пользователям функции. o   Customer Delight – фичи, которые не обязательно запрашивают пользователи, но которые будут им полезны. Практические техники приоритизации помогут определить важность каждой задачи и сбалансировать работу над проектом Подводя итог тому, что такое приоритизация и рассмотренным подходам к расстановке приоритетов, отметим, что многие из них применимы не только к ИТ-сфере и управлению проектами по цифровизации, включая разработку и внедрение Big Data систем. По сути, приоритизация – это ежедневная задача каждого бизнес-аналитика, менеджера проектов и руководителя. Поэтому знание методов и техник расстановки приоритетов, как и подходов к экспресс-анализу, будет полезно и для начальника любого уровня. Другие прикладные вопросы практического применения системного и бизнес-анализа рассматриваются на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве: Аналитика больших данных для руководителей Анализ и оптимизация бизнес-процессов

 Смотреть расписание занятий

 Зарегистрироваться на курс Источники 1.       https://analytics.infozone.pro/babok/chapters-of-babok-version-3/ 2.       https://ru.wikipedia.org/wiki/Расстановка_приоритетов_в_портфеле_проектов 3.       https://www.advanta-group.ru/blog/kak-rasstavlat-prioritety-sredi-proektov-vasej-kompanii/ 4.       https://analystpages.ru/2018/11/12/requirements-prioritization/ 5.       https://pmjournal.ru/articles/keysy/kak-rasschitat-prioritet-proekta/ 6.       https://pmexpert.ru/press-center/news-world/detail.php?ID=11401 7.       https://dou.ua/lenta/articles/prioritization-approach/ 8.       https://medium.com/@itamargilad/why-impact-effort-prioritization-doesnt-work-57d141fafc2c 9.       https://foldingburritos.com/kano-model/ 10.   https://vc.ru/hr/63226-metod-moscow-kak-sfokusirovatsya-na-glavnom-i-stat-effektivnee 11.   https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ 12.   https://www.processimpact.com/articles/prioritizing.pdf 13.  https://adamnash.blog/2009/07/22/guide-to-product-planning-three-feature-buckets/ Read the full article