Подборка статей "Бизнес-процессы: определение, классификация, характеристики"

🖇 Бизнес-процессы в организации: что это такое и зачем они нужны
🖇 Что такое бизнес-процесс и как его описать
🖇 Классификация бизнес-процессов
🖇 Классификация бизнес-процессов организации
🖇 Бизнес-процесс: что это, виды, управление и автоматизация
🖇 Большой гайд по управлению бизнес-процессами
🖇 Что такое бизнес-процесс и описание бизнес-процесса
🖇 Виды бизнес процессов и их составляющие
🖇 Часто задаваемые вопросы по бизнес-процессам
🖇 Оптимизация рабочего процесса: полное руководство
🖇 Зачем и как описывать бизнес-процессы?
🖇 Компоненты бизнес-процессов
🖇 Бизнес-анализ для начинающих: что такое бизнес-процесс – основы процессного подхода к управлению
🖇 Книги по бизнес процессам, которые обязан прочитать каждый

#подборка #статьи | @notes_analyst

​​📑 Почему потоковые очереди не превращают RabbitMQ в Kafka

Автор Анна Вичугова

"Чем потоковые очереди в RabbitMQ похожи на топики Apache Kafka, в чем между ними разница и как это проявляется на больших нагрузках. Почему масштабируемость и производительность стриминговых очередей RabbitMQ все-таки ниже, чем у топиков Kafka."

Читать статью

📑 От Job Story к User Story. Часть 1. Введение в связь артефактов и циклов

Автор - Рычихин Павел, который является Менеджером продукта и Бизнес-системным аналитиком:

"Данная публикация открывает серию статей, в которой я покажу путь от пользовательской потребности через Job Story к пользовательской истории и связи с Юнит-экономикой, используя понятные артефакты и взаимосвязи между ними."

Читать статью

📑 Почему бюрократия убивает горизонтальные коммуникации: анализ иерархических структур и Agile-подходов

Автор - Михаил Вязанкин:

"Во многих крупных компаниях цикл принятия решений растягивается на дни, а иногда на недели. В период, когда мир стремительно меняется, такой подход становится не инструментом управления, а помехой для развития и коммуникаций. В противовес бюрократии часто ставят Agile — гибкие коммуникации, которые помогают достигать более высоких результатов. В чём проблема бюрократии? Можно ли её победить? В чём преимущество Agile-подхода? Как внедрить его в компании без хаоса? С этими вопросами разбираемся в статье"

Читать статью

Привет, коллеги! 👋

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

Вот ключевые шаги:

 1. Идентификация процесса

Прежде чем что-то улучшать, нужно понять:  
▪︎ Какой процесс мы рассматриваем?
▪︎ Какие у него границы? (Что на входе, что на выходе, кто участвует)  
▪︎ Зачем мы его анализируем? (Сократить время, уменьшить ошибки, подготовить к автоматизации)  

Пример:  Процесс «Возврат товара» начинается с заявления клиента и заканчивается переводом денег или заменой товара. Участники: клиент, менеджер, бухгалтерия, склад.

2. Описание текущего состояния (As-Is)

Здесь важно зафиксировать, как процесс работает сейчас  - без прикрас и «как должно быть».  
▪︎ Собираем информацию: интервью, наблюдение, документы.  
▪︎ Визуализируем в нотации (BPMN, блок-схема, SIPOC).  
▪︎ Выявляем проблемные места: узкие горлышки, дублирование, рутинные операции

❗️Важно: Не пропускайте этот этап! Попытки оптимизировать процесс без понимания его текущего состояния часто приводят к новым ошибкам.  

3. Разработка будущего состояния (To-Be)
  
Теперь проектируем, как процесс должен работать после изменений.  
▪︎ Ставим четкие цели: что хотим улучшить? (Скорость, качество, стоимость)  
▪︎ Убираем лишние шаги, перераспределяем зоны ответственности.  
▪︎ Продумываем возможности автоматизации.
▪︎ Рисуем новую схему и готовим регламент. 

Пример улучшения: Ручную проверку заявки тремя отделами заменяем автоматизированной системой с одним контролем менеджера.
  
4. Внедрение изменений  

Самый сложный этап — перевести теорию в практику:  
▪︎ Пишем инструкции для сотрудников.  
▪︎ Проводим обучение.  
▪︎ Запускаем пилотный проект (например, в одном филиале или для части заказов).  
▪︎ Настраиваем инструменты (CRM, ERP).  

❕️Совет: Внедряйте изменения постепенно и собирайте обратную связь от команды. 

5. Контроль и мониторинг
  
После внедрения важно измерять результаты:  
▪︎Какие KPI изменились? (Время выполнения, количество ошибок, стоимость)  
▪︎ Используем дашборды (Power BI, Google Data Studio) для наглядности.  
▪︎ Выявляем новые узкие места - процесс никогда не бывает идеальным с первого раза.  

6. Постоянное улучшение
  
Бизнес-процессы - это не «разовая настройка».
Работа с ними строится по циклу:  
- Планируем изменения → внедряем → проверяем результаты → корректируем.  

Несколько рекомендаций:

✅  Начинайте с критических процессов -  тех, что сильнее всего влияют на прибыль или клиентский опыт.  
✅  Вовлекайте исполнителей -  те, кто работает с процессом ежедневно, знают его слабые места.  
✅  Избегайте избыточной детализации - слишком сложные схемы трудно поддерживать.  
✅  Тестируйте изменения - пилотные запуски помогут выявить недочёты до массового внедрения.  
✅  Документируйте всё - это сэкономит время при аудитах и обучении новых сотрудников.  

И запомните❕️
Хороший процесс - это не тот, который красив на бумаге, а тот, который работает без сбоев в реальности.

#теоретическиезаметки | @notes_analyst

📑 Разработка высоконагруженных API: проблемы, решения, практические рекомендации

"Ваш проект взлетел. Первые пользователи превратились в тысячи. Тысячи стали десятками тысяч. Метрики в дашбордах рисуют красивую кривую, устремленную вверх. Но есть и другие кривые, которые ползут вверх с не меньшей скоростью. Время ответа сервера. Количество ошибок 502 и 504.

То, что летало на ста запросах в секунду, начинает задыхаться на десяти тысячах. Это не ошибка, это физика. Архитектура для этих двух миров — это как велосипед и грузовой поезд. Они оба едут, но задачи у них разные. Так что давайте забудем про теорию и посмотрим, где обычно рвется и как это чинить, чтобы не переписывать все с нуля каждый раз, когда у вас прибавляется нолик в статистике пользователей."

Читать статью

​​📑 Схема GraphQL

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

Схема в GraphQL — это описание структуры API, написанное на специальном языке SDL (Schema Definition Language). Она определяет:

- Какие типы данных существуют в системе;
- Какие операции (запросы, мутации, подписки) доступны клиентам;
- Какие поля можно запрашивать у каждого типа;
- Какие аргументы принимают операции и поля."

Читать далее..

Друзья, всем привет! 👋
Сегодня предлагаю небольшой интерактив – тест на знание основ бизнес-процессов. Проверьте, насколько хорошо вы ориентируетесь в этой теме! ⬇️

📑 Взаимодействие микросервисов: проблемы, решения, практические рекомендации

"Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось взаимодействовать. И мечта превратилась в сложную, многомерную головоломку."

"Переход на микросервисы — это не просто технический рефакторинг. Это полная смена парадигмы мышления для инженеров, тестировщиков и менеджеров."

Читать статью

📑 Docs as Code: наш опыт документирования с LaTeX и Dev container

"В мире разработки мы постоянно сталкиваемся с технической документацией — она повсюду, от спецификаций API до архитектурных решений. И мы хотим, чтобы документация была структурированной, актуальной и удобной… но в реальности чаще имеем дело с хаотичным набором разрозненных материалов, которые теряются между Confluence, почтой и Google Docs, стремительно устаревают и выглядят небрежно, с «плывущими» таблицами и запутанной структурой. Представили этот беспорядок?

Хорошая новость: есть способ автоматизировать и стандартизировать документацию, сделав её такой же управляемой, как код — через модель docs as code.

В статье вместе вспомним базовые принципы этого подхода, расскажем про наш опыт документирования и поделимся репозиторием с готовым шаблоном LaTeX для максимально быстрого старта без установки зависимостей!"

Читать статью

📑 Должен ли аналитик уметь всё?

Автор: Полина - старший системный аналитик на проекте разработки и развития решений по управления данными в компании "Цифровые сервисы"

"На одной из конференций по аналитике увидела интересный слайд, на котором был перечислен набор аббревиатур и вопрос для размышления: "Должен ли аналитик уметь все?".

Скажу честно, ряд аббревиатур я увидела впервые.

Решила посвятить статью как раз этим аббревиатурам, что есть что и привести практические примеры"

Читать статью

​​📑 Они говорят «неудобно», но продолжают пользоваться

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

Читать статью

​​📑 Kafka теперь RabbitMQ? Очереди общего доступа с KIP-932

Автор: Анна Вичугова
"Что такое очереди общего доступа в Kafka и зачем они нужны: как KIP-932 расширяет возможности самой популярной платформы потоковой передачи событий, чем группа общего доступа отличается от классической группы потребителей."

Читать статью

📑 Скетч системного дизайна: как одна схема решает множество проблем на старте проекта

От Автора: "Если в вашей практике на начальном этапе анализа проекта обозначаются все контексты и границы взаимодействия систем, то скорее всего у вас хорошо развита культура системного дизайна и данная статья для вас не имеет практического значения. В противном случае предлагаю уделить 5 минут вашего времени для ознакомления с материалом."

Читать статью

​​📑 Дизайнер х Аналитик: где заканчивается аналитика и начинается дизайн?

"Рынок IT меняется с такой скоростью, что за ним иногда трудно угнаться: новые технологии, методологии, роли — всё постоянно меняется. Из-за этого границы между профессиями часто становятся размазанными. Если разработчики чётко знают свой стек, задачи и техдолг, то у дизайнеров и аналитиков всё гораздо более гибко, потому что их работа опирается на коммуникацию, логику и потребности людей. Часто дизайнеры и аналитики начинают работать вместе еще на самых ранних стадиях проекта — именно там, где чаще всего царит хаос.

И вот здесь начинается путаница. Часто не совсем ясно, кто за что отвечает. В одной команде UX-дизайнер делает всё: от сбора требований до создания прототипов, а в другой — он ждет четкого ТЗ от аналитика. И тогда возникает вопрос: где заканчивается аналитика и начинается дизайн? Давайте разберемся."

Читать статью