Привет, коллеги! 👋
Сегодня поговорим о нотации EPC, которая помогает нам, аналитикам, четко и наглядно моделировать бизнес-процессы.
EPC (Event-Driven Process Chain, или "событийная цепочка процессов") - это графический язык для описания последовательности событий, функций и логических связей в бизнес-процессах. Это как дорожная карта вашего процесса, с понятными указателями и перекрестками!
Зачем аналитику нужен EPC?
▪️Визуализация "как есть" (as-is): понять текущее состояние процесса, выявить узкие места и проблемные зоны.
▪️Проектирование "как должно быть" (to-be): разработать новую, оптимизированную версию процесса.
▪️Анализ и улучшение: упростить, автоматизировать, сделать процесс более эффективным.
▪️Коммуникация: легко объяснить процесс заказчикам, разработчикам и другим участникам. EPC-диаграммы понятны и наглядны.
▪️Документирование: создание четкой и структурированной документации по процессам.
⬆️ В карусели к этому посту вы найдете:
▫️Основные элементы EPC: События, функции, логические операторы (И, ИЛИ, исключающее ИЛИ) и др.
▫️Ключевые правила моделирования: чтобы диаграммы были понятными и не запутывали.
▫️Рекомендации по созданию эффективных EPC-диаграмм.
▫️Плюсы и минусы использования нотации EPC.
Хотите углубиться? Вот полезные ссылки⬇️
🖇 Моделирование бизнес-процессов » Нотация EPC
🖇 Работа в MS Visio » Нотация EPC
🖇 Практика применения стандарта моделирования EPC
🖇 Событийная цепочка процессов
🖇 Как моделировать бизнес-процессы в нотации eEPC?
🖇 Один пример и три нотации: сравниваем BPMN, EPC и DMN
🖇 Бизнес процессы в нотации epc » Примеры диаграмм
#теоретическиезаметки #подборка #статьи | @notes_analyst
Сегодня поговорим о нотации EPC, которая помогает нам, аналитикам, четко и наглядно моделировать бизнес-процессы.
EPC (Event-Driven Process Chain, или "событийная цепочка процессов") - это графический язык для описания последовательности событий, функций и логических связей в бизнес-процессах. Это как дорожная карта вашего процесса, с понятными указателями и перекрестками!
Зачем аналитику нужен EPC?
▪️Визуализация "как есть" (as-is): понять текущее состояние процесса, выявить узкие места и проблемные зоны.
▪️Проектирование "как должно быть" (to-be): разработать новую, оптимизированную версию процесса.
▪️Анализ и улучшение: упростить, автоматизировать, сделать процесс более эффективным.
▪️Коммуникация: легко объяснить процесс заказчикам, разработчикам и другим участникам. EPC-диаграммы понятны и наглядны.
▪️Документирование: создание четкой и структурированной документации по процессам.
▫️Основные элементы EPC: События, функции, логические операторы (И, ИЛИ, исключающее ИЛИ) и др.
▫️Ключевые правила моделирования: чтобы диаграммы были понятными и не запутывали.
▫️Рекомендации по созданию эффективных EPC-диаграмм.
▫️Плюсы и минусы использования нотации EPC.
Хотите углубиться? Вот полезные ссылки
🖇 Моделирование бизнес-процессов » Нотация EPC
🖇 Работа в MS Visio » Нотация EPC
🖇 Практика применения стандарта моделирования EPC
🖇 Событийная цепочка процессов
🖇 Как моделировать бизнес-процессы в нотации eEPC?
🖇 Один пример и три нотации: сравниваем BPMN, EPC и DMN
🖇 Бизнес процессы в нотации epc » Примеры диаграмм
#теоретическиезаметки #подборка #статьи | @notes_analyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍6
📑 Проектирование REST API: проблемы, решения, практические рекомендации
"API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.
Латать дыры по мере их обнаружения — это путь в никуда. Нужно не тушить пожары, а строить систему так, чтобы она не загоралась. Безопасность, производительность и удобство использования должны закладываться в архитектуру с первого дня. Это контракт. Если контракт составлен плохо, его будут нарушать."
Читать статью
"API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.
Латать дыры по мере их обнаружения — это путь в никуда. Нужно не тушить пожары, а строить систему так, чтобы она не загоралась. Безопасность, производительность и удобство использования должны закладываться в архитектуру с первого дня. Это контракт. Если контракт составлен плохо, его будут нарушать."
Читать статью
Машинное обучение в финтехе
"Машинное обучение в финансовой сфере — это полноценный инструмент, который уже меняет подходы к анализу данных, принятию решений и автоматизации процессов. Как именно эта технология работает, и какие конкретные задачи она решает? Поговорим об этом в этой статье."
Читать статью
"Машинное обучение в финансовой сфере — это полноценный инструмент, который уже меняет подходы к анализу данных, принятию решений и автоматизации процессов. Как именно эта технология работает, и какие конкретные задачи она решает? Поговорим об этом в этой статье."
Читать статью
📑 Документация как инструмент управления проектом
В статье аналитик Банка ДОМ. РФ, Василий Белькович, делится опытом построения системы документации для сложной корпоративной IDM-системы.
Описывает цели создания такой системы и представляет подход к разделению документации на три части, объясняя, как каждая из них помогает решать поставленные задачи.
Читать статью
В статье аналитик Банка ДОМ. РФ, Василий Белькович, делится опытом построения системы документации для сложной корпоративной IDM-системы.
Описывает цели создания такой системы и представляет подход к разделению документации на три части, объясняя, как каждая из них помогает решать поставленные задачи.
Читать статью
👍4❤2
📑 Запускаем Kafka в режиме KRaft на Windows через WSL
Данная статья посвящается тем, кто начинает изучать Kafka и собирается установить ее для тестирования в среде Windows.
Читать статью
Часть 2: Практика Kafka: проектирование топиков и обмен сообщениями
В данной статье пойдет речь о структуре и обработке сообщений Kafkа
Читать статью
Данная статья посвящается тем, кто начинает изучать Kafka и собирается установить ее для тестирования в среде Windows.
Читать статью
Часть 2: Практика Kafka: проектирование топиков и обмен сообщениями
В данной статье пойдет речь о структуре и обработке сообщений Kafkа
Читать статью
🔥4👍1
Как мы наводим порядок в BI: опыт внедрения процесса ревью отчётов
В этой статье — Ринат Хабибрахманов, руководитель практики BI в Лемана Тех, и Лариса Фернандес, ведущий разработчик аналитических систем, — рассказывают, как они в своей команде шаг за шагом внедряли процесс ревью Power BI-отчётов, чтобы вернуть контроль, улучшить качество аналитики и восстановить доверие пользователей к BI-системе.
Читать статью
В этой статье — Ринат Хабибрахманов, руководитель практики BI в Лемана Тех, и Лариса Фернандес, ведущий разработчик аналитических систем, — рассказывают, как они в своей команде шаг за шагом внедряли процесс ревью Power BI-отчётов, чтобы вернуть контроль, улучшить качество аналитики и восстановить доверие пользователей к BI-системе.
Читать статью
❤4
📑 Примеры бизнес-применения модели C4
В данной статье Автор поднимает проблему сложности описания бизнес-процессов и предлагает решение в виде метода C4 – подхода из мира разработки ПО, который позволяет структурировать контекст на несколько уровней для лучшего понимания взаимосвязей и функционирования системы.
Читать статью
В данной статье Автор поднимает проблему сложности описания бизнес-процессов и предлагает решение в виде метода C4 – подхода из мира разработки ПО, который позволяет структурировать контекст на несколько уровней для лучшего понимания взаимосвязей и функционирования системы.
Читать статью
Привет, коллеги! 👋
Сегодня поговорим о таком инструменте в арсенале аналитика как – нотации IDEF0.
Если вы хотите четко и структурированно описывать бизнес-процессы компании, моделировать их и находить узкие места, то IDEF0 – ваш верный помощник.
IDEF0 (Integration Definition for Function Modeling) – это методология функционального моделирования, которая позволяет представить бизнес-процесс в виде набора взаимосвязанных функций (работ, действий). Модель IDEF0 показывает, что делает компания, а не как она это делает (для этого есть другие нотации).
Зачем IDEF0 аналитику? 🤔
▫️Визуализация сложных процессов: позволяет разложить сложный процесс на более простые, понятные блоки, что облегчает его анализ и понимание.
▫️Выявление взаимосвязей: модель четко показывает, как функции взаимодействуют между собой, какие данные используются и какие ресурсы необходимы.
▫️Поиск узких мест и оптимизация: благодаря наглядности модели, легко обнаружить области, где процесс работает неэффективно, и предложить варианты оптимизации.
▫️Улучшение коммуникации: IDEF0 создает общий язык между бизнес-заказчиками и разработчиками, что снижает риск недопонимания и ошибок.
▫️Основа для автоматизации: модель IDEF0 может служить отправной точкой для проектирования информационных систем, автоматизирующих бизнес-процессы.
⬆️ В картинках к посту вы найдете:
▪️Основные элементы IDEF0 (блоки, стрелки).
▪️Виды диаграмм (верхнего уровня и детализированной).
▪️Плюсы и минусы использования
Чем IDEF0 полезна в работе? 💼
Представьте, что перед вами стоит задача – оптимизировать процесс обработки заказов в интернет-магазине. С помощью IDEF0 вы сможете:
1. Разложить процесс на отдельные функции: "Прием заказа", "Проверка наличия товара", "Оплата", "Доставка".
2. Определить входящие данные для каждой функции: "Информация о заказе", "Данные о клиенте", "Информация о товаре".
3. Выявить управляющие факторы: "Правила обработки заказов", "Наличие товара на складе".
4. Определить ресурсы: "Сотрудники склада", "Транспорт".
Анализируя эту модель, вы легко сможете найти "узкие горлышки" и предложить решения по их устранению.
Для более глубоко погружения в данную тему, ловите подборку статей⬇️
🖇 Методология функционального моделирования IDEF0
🖇 IDEF0. Знакомство с нотацией и пример использования
🖇 Азы моделирования в idef0
🖇 Нотация IDEF0
🖇 Пример использования принципа декомпозиции в IDEF0
🖇 Два способа построения моделей бизнес-процессов в IDEF0
🖇 Создание схемы IDEF0
🖇 Функциональное моделирование бизнес-процессов машиностроительного производства
Ставьте огонёчки 🔥 если используете данную нотацию в своей работе)
#теоретическиезаметки #подборка #статьи | @notes_analyst
Сегодня поговорим о таком инструменте в арсенале аналитика как – нотации IDEF0.
Если вы хотите четко и структурированно описывать бизнес-процессы компании, моделировать их и находить узкие места, то IDEF0 – ваш верный помощник.
IDEF0 (Integration Definition for Function Modeling) – это методология функционального моделирования, которая позволяет представить бизнес-процесс в виде набора взаимосвязанных функций (работ, действий). Модель IDEF0 показывает, что делает компания, а не как она это делает (для этого есть другие нотации).
Зачем IDEF0 аналитику? 🤔
▫️Визуализация сложных процессов: позволяет разложить сложный процесс на более простые, понятные блоки, что облегчает его анализ и понимание.
▫️Выявление взаимосвязей: модель четко показывает, как функции взаимодействуют между собой, какие данные используются и какие ресурсы необходимы.
▫️Поиск узких мест и оптимизация: благодаря наглядности модели, легко обнаружить области, где процесс работает неэффективно, и предложить варианты оптимизации.
▫️Улучшение коммуникации: IDEF0 создает общий язык между бизнес-заказчиками и разработчиками, что снижает риск недопонимания и ошибок.
▫️Основа для автоматизации: модель IDEF0 может служить отправной точкой для проектирования информационных систем, автоматизирующих бизнес-процессы.
▪️Основные элементы IDEF0 (блоки, стрелки).
▪️Виды диаграмм (верхнего уровня и детализированной).
▪️Плюсы и минусы использования
Чем IDEF0 полезна в работе? 💼
Представьте, что перед вами стоит задача – оптимизировать процесс обработки заказов в интернет-магазине. С помощью IDEF0 вы сможете:
1. Разложить процесс на отдельные функции: "Прием заказа", "Проверка наличия товара", "Оплата", "Доставка".
2. Определить входящие данные для каждой функции: "Информация о заказе", "Данные о клиенте", "Информация о товаре".
3. Выявить управляющие факторы: "Правила обработки заказов", "Наличие товара на складе".
4. Определить ресурсы: "Сотрудники склада", "Транспорт".
Анализируя эту модель, вы легко сможете найти "узкие горлышки" и предложить решения по их устранению.
Для более глубоко погружения в данную тему, ловите подборку статей
🖇 Методология функционального моделирования IDEF0
🖇 IDEF0. Знакомство с нотацией и пример использования
🖇 Азы моделирования в idef0
🖇 Нотация IDEF0
🖇 Пример использования принципа декомпозиции в IDEF0
🖇 Два способа построения моделей бизнес-процессов в IDEF0
🖇 Создание схемы IDEF0
🖇 Функциональное моделирование бизнес-процессов машиностроительного производства
Ставьте огонёчки 🔥 если используете данную нотацию в своей работе)
#теоретическиезаметки #подборка #статьи | @notes_analyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍5
📑 Секреты создания эффективного REST API: гайд для системных аналитиков
Автор - Дарья Борисова, системный аналитик в ПСБ.
В статье Дарья рассказывает об оптимизации REST API в реальных боевых условиях, когда нужно быстро решать проблемы с нагрузкой и сроками. В ней рассматриваются вопросы снижения количества запросов, выбора места для расчетов, стандартизации ответов, умного кеширования и важности health-check. Автор делится лайфхаками, накопленными в процессе работы и рассказывает о компромиссах, на которые приходится идти ради быстрого решения проблем.
Читать статью
Автор - Дарья Борисова, системный аналитик в ПСБ.
В статье Дарья рассказывает об оптимизации REST API в реальных боевых условиях, когда нужно быстро решать проблемы с нагрузкой и сроками. В ней рассматриваются вопросы снижения количества запросов, выбора места для расчетов, стандартизации ответов, умного кеширования и важности health-check. Автор делится лайфхаками, накопленными в процессе работы и рассказывает о компромиссах, на которые приходится идти ради быстрого решения проблем.
Читать статью
👍3
📑 Эволюция процессов: от классической автоматизации до самооптимизирующихся ИИ-агентов
Автор - Игорь Морозов, архитектор в Platformeco:
"На True Tech Arch #7, конференции для IT-архитекторов я рассказывал, как ИИ меняет интеграцию и автоматизацию. В этом материале по мотивам моего доклада я покажу, при каких обстоятельствах создание ИТ-продуктов уйдет доменным экспертам, появится возможность автоматизации недоступных ранее процессов и с какими вызовами это столкнется."
Читать статью
Автор - Игорь Морозов, архитектор в Platformeco:
"На True Tech Arch #7, конференции для IT-архитекторов я рассказывал, как ИИ меняет интеграцию и автоматизацию. В этом материале по мотивам моего доклада я покажу, при каких обстоятельствах создание ИТ-продуктов уйдет доменным экспертам, появится возможность автоматизации недоступных ранее процессов и с какими вызовами это столкнется."
Читать статью
👍2
📑 Альтернативная нотация описания архитектуры ИТ систем
Когда-то, много лет тому назад, в начале своей карьеры системного и бизнес аналитика, Автор статьи открыл для себя BPMN 2.0. Эта нотация настолько идеально вписалась в его рабочий процесс, что он моментально перешел от текстовых конспектов к схемам, экономя массу времени и энергии. Но, как это часто бывает, то, что "зашло", со временем трансформируется под новые задачи. В этой статье автор делится опытом, как его любовь к BPMN переросла в инструмент системной и солюшен архитектуры, который помогает эффективно решать сложные корпоративные задачи.
Читать статью
Когда-то, много лет тому назад, в начале своей карьеры системного и бизнес аналитика, Автор статьи открыл для себя BPMN 2.0. Эта нотация настолько идеально вписалась в его рабочий процесс, что он моментально перешел от текстовых конспектов к схемам, экономя массу времени и энергии. Но, как это часто бывает, то, что "зашло", со временем трансформируется под новые задачи. В этой статье автор делится опытом, как его любовь к BPMN переросла в инструмент системной и солюшен архитектуры, который помогает эффективно решать сложные корпоративные задачи.
Читать статью
Шпаргалка по проектированию REST API
"Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно."
Читать статью
"Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно."
Читать статью
👍2
Привет, Коллеги! 👋
Моделирование бизнес-процессов – мощный инструмент для оптимизации работы компании, но, как и любой инструмент, его можно использовать неправильно. Сегодня разберем 5 самых распространенных ошибок, которые допускают аналитики при моделировании.
Ошибка №1: Отсутствие четкой цели 🎯
Прежде чем браться за моделирование, необходимо четко определить, зачем мы это делаем. Какую проблему решаем? Какого результата хотим достичь? Без четкой цели модель превращается в бесполезный набор схем и диаграмм.
Как избежать: Четко формулируйте цель моделирования (например, "Сократить время обработки заказа на 20%"). Определите метрики, по которым будете оценивать результат.
Ошибка №2: Слишком большой уровень детализации 🔎
Детальная модель – это хорошо, но только до определенного момента. Если вы утонете в мелочах, то потеряете общую картину и упустите важные взаимосвязи.
Как избежать: Применяйте принцип "достаточной детализации". Начните с модели верхнего уровня и углубляйтесь только там, где это действительно необходимо.
Проверьте себя: спросите себя "какую пользу несет добавление этой детали в модель?". Если ответ - никакой, то деталь не нужна.
Ошибка №3: Игнорирование мнения экспертов 🗣
Бизнес-процессы – это не теоретические схемы, а реальная работа людей. Если вы игнорируете мнение экспертов (сотрудников, которые непосредственно участвуют в процессе), то рискуете создать модель, которая не соответствует действительности.
Как избежать: Вовлекайте экспертов в процесс моделирования. Проводите интервью, устраивайте воркшопы, собирайте обратную связь.
Ошибка №4: Неправильный выбор нотации ✍️
Разные нотации (BPMN, IDEF0, EPC) подходят для разных целей и типов процессов. Если вы выберете неправильную нотацию, то не сможете адекватно представить процесс и найти точки для улучшения.
Как избежать: Изучите особенности разных нотаций и выбирайте ту, которая лучше всего подходит для вашего случая.
▫️Если в вашей модели главное - показать, что происходит -> используйте BPMN.
▫️Если в вашей модели главное - показать, как функция влияет на другие функции -> используйте IDEF0.
▫️Если в вашей модели главное - показать последовательность событий -> используйте EPC.
Ошибка №5: Забываем об изменениях 🔄
Бизнес-процессы постоянно меняются, а модель, которую вы создали сегодня, может устареть уже завтра. Если вы не поддерживаете модель в актуальном состоянии, то она потеряет свою ценность.
Как избежать: Включите поддержание модели в регламент работы. Регулярно пересматривайте модель и вносите необходимые изменения.
Подумайте об инструменте: выберите инструмент моделирования бизнес-процессов, который помогает вести историю изменений.
Как итог: Суть всего вышесказанного можно уместить в одно правило: ваша модель должна быть полезна.
Все эти ошибки так или иначе мешают этому. Предотвращая их, вы сможете создать не просто диаграмму, а реальный рабочий элемент.
@notes_analyst
Моделирование бизнес-процессов – мощный инструмент для оптимизации работы компании, но, как и любой инструмент, его можно использовать неправильно. Сегодня разберем 5 самых распространенных ошибок, которые допускают аналитики при моделировании.
Ошибка №1: Отсутствие четкой цели 🎯
Прежде чем браться за моделирование, необходимо четко определить, зачем мы это делаем. Какую проблему решаем? Какого результата хотим достичь? Без четкой цели модель превращается в бесполезный набор схем и диаграмм.
Как избежать: Четко формулируйте цель моделирования (например, "Сократить время обработки заказа на 20%"). Определите метрики, по которым будете оценивать результат.
Ошибка №2: Слишком большой уровень детализации 🔎
Детальная модель – это хорошо, но только до определенного момента. Если вы утонете в мелочах, то потеряете общую картину и упустите важные взаимосвязи.
Как избежать: Применяйте принцип "достаточной детализации". Начните с модели верхнего уровня и углубляйтесь только там, где это действительно необходимо.
Проверьте себя: спросите себя "какую пользу несет добавление этой детали в модель?". Если ответ - никакой, то деталь не нужна.
Ошибка №3: Игнорирование мнения экспертов 🗣
Бизнес-процессы – это не теоретические схемы, а реальная работа людей. Если вы игнорируете мнение экспертов (сотрудников, которые непосредственно участвуют в процессе), то рискуете создать модель, которая не соответствует действительности.
Как избежать: Вовлекайте экспертов в процесс моделирования. Проводите интервью, устраивайте воркшопы, собирайте обратную связь.
Ошибка №4: Неправильный выбор нотации ✍️
Разные нотации (BPMN, IDEF0, EPC) подходят для разных целей и типов процессов. Если вы выберете неправильную нотацию, то не сможете адекватно представить процесс и найти точки для улучшения.
Как избежать: Изучите особенности разных нотаций и выбирайте ту, которая лучше всего подходит для вашего случая.
▫️Если в вашей модели главное - показать, что происходит -> используйте BPMN.
▫️Если в вашей модели главное - показать, как функция влияет на другие функции -> используйте IDEF0.
▫️Если в вашей модели главное - показать последовательность событий -> используйте EPC.
Ошибка №5: Забываем об изменениях 🔄
Бизнес-процессы постоянно меняются, а модель, которую вы создали сегодня, может устареть уже завтра. Если вы не поддерживаете модель в актуальном состоянии, то она потеряет свою ценность.
Как избежать: Включите поддержание модели в регламент работы. Регулярно пересматривайте модель и вносите необходимые изменения.
Подумайте об инструменте: выберите инструмент моделирования бизнес-процессов, который помогает вести историю изменений.
Как итог: Суть всего вышесказанного можно уместить в одно правило: ваша модель должна быть полезна.
Все эти ошибки так или иначе мешают этому. Предотвращая их, вы сможете создать не просто диаграмму, а реальный рабочий элемент.
@notes_analyst
👍9
📑 Как сделать сложный технический текст простым и понятным: приемы из практики технического писателя
"Главная цель любой инструкции — дать ответ на вопрос читателя. Инструкция не выполняет свою функцию, если читатель не смог быстро найти нужную ему информацию. Поэтому написать текст инструкции мало — нужно ещё и оформить его так, чтобы помочь пользователю в его нелёгкой задаче. Для этого можно использовать ряд универсальных приёмов. "
В данной статье Анна Гончарова, ведущий технический писатель в компании Bercut , разберет пять практических приемов из их руководства по стилю, которые помогут структурировать материал и упростить восприятие.
Читать статью
"Главная цель любой инструкции — дать ответ на вопрос читателя. Инструкция не выполняет свою функцию, если читатель не смог быстро найти нужную ему информацию. Поэтому написать текст инструкции мало — нужно ещё и оформить его так, чтобы помочь пользователю в его нелёгкой задаче. Для этого можно использовать ряд универсальных приёмов. "
В данной статье Анна Гончарова, ведущий технический писатель в компании Bercut , разберет пять практических приемов из их руководства по стилю, которые помогут структурировать материал и упростить восприятие.
Читать статью
👍6