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

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

Здесь собраны практически все вопросы, которые вы можете услышать на собеседовании системного аналитика. Читайте, пользуйтесь, готовьтесь — надеюсь, вам пригодится при трудоустройстве.

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

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

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

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

А нужно ли вообще назначать владельца бизнес-процесса?

Такая постановка вопроса наверняка вызовет возмущение со стороны сторонников ВРМ, так как у любого бизнес-процесса должен быть ответственный, который и называется его владельцем. Дело в том, что такая позиция (должность) в КВАЛИФИКАЦИОННОМ СПРАВОЧНИКЕ ДОЛЖНОСТЕЙ РУКОВОДИТЕЛЕЙ, СПЕЦИАЛИСТОВ И ДРУГИХ СЛУЖАЩИХ (Утвержден Постановлением Минтруда РФ от 21 августа 1998 г. N 37, в ред. Постановлений Минтруда РФ от 12.11.2003 № 75, Приказов Минсоцразвития РФ от 14.03.2011 № 194, Приказов Минтруда РФ от 27.03.2018 № 197) отсутствует. А это означает, что такая позиция создана искусственно с целью определения лица, который осуществляет необходимые для выполнения операционного процесса функции. Однако на практике деятельность компании, в т.ч. выполнение операционных процессов, осуществляется сотрудниками независимо от того, назначено какое-либо лицо «владельцем» процесса или нет.

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

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

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

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

Там, где другие строят с нуля, Nestlé просто открывает шаблон. Где кто-то ищет «как сделать», Iberdrola просто следует собственному кодексу автоматики.

И чем сложнее технологии, тем ценнее становится не оборудование — а порядок.

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

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

Поговорим про устройство робота, железо и софт на борту, прикладные задачи и ближайшее будущее.

Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.

Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.

Привет! Это Илья Петряшин, старший дата-сайентист в команде горизонтальных ML-технологий в Авито, и Артём Трофименко, старший аналитик по коммуникациям в Авито. Мы вместе создали главную продуктовую метрику Авито. В статье расскажем, зачем нам понадобилась такая метрика, с какими трудностями столкнулись и как прошли путь от формализации понятия «договорённость» до обучения модели и внедрения метрики в аналитику и цели компании.

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

А четвертая оказалось самой интересной. Где даже с неполадками сети и падениями сервиса был сделан лишь один заказ. И произведена одна оплата. Благодаря чему пришла желаемая теплая пицца. Которую хотел наш дорогой покупатель.

Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью Outbox Pattern.

Mobile System Design — один из ключевых навыков мобильного инженера.

Именно он часто определяет уровень зрелости: в реальной работе, на собеседованиях и в матрицах компетенций компаний.

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

В этой статье я систематизирую Mobile System Design как дисциплину: покажу, какие навыки действительно важны и как они проверяются. Это не личное мнение, а выжимка из опыта инженеров, требований собеседований, литературы и практики команд.

Эта статья была написана мной и опубликована в отраслевом научном журнале более четверти века назад, когда я работал в головном НИИ железнодорожной отрасли (ВНИИЖТ МПС) в должности заместителя заведующего лабораторией и занимался вопросами научно-методического обеспечения задач управления производственными процессами путевого хозяйства железных дорог России, автоматизацией функций и применением информационных технологий для нужд путевого хозяйства.

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

Привет, коллеги. Меня зовут Александр Попов, я представляю группу продуктовых дизайнеров и UX-исследователей группы компаний «Цифра».

Сегодня поговорим о теме, которая заставляет многих из нас чесать в затылке, — как измерить удовлетворенность пользователей в суровом мире enterprise-продуктов? В том самом, где пользователи ваш продукт не выбирают, а получают его «в нагрузку» к своей работе. Это как со школьной формой: носить надо, нравится или нет — вопрос десятый. Но если форма жмет, трет и расползается по швам, учеба превращается в пытку.

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

Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс?

Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его активно продвигает Ринат Абдуллин в материалах по работе с LLM. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. Это не панацея, но SGR серьёзно снижает количество ошибок, делает процесс прозрачнее, а также позволяет тестировать отдельные компоненты рассуждений.

Однажды в одной компании решили: «Сделаем процессы в ITSM-системе точь-в-точь такими, как в жизни! Только ни в коем случае не продумаем все как следует…» После этого их сервис деск задушили баги, а клиенты похоронили саппорт своими заявками. Бу!

Привет, Хабр, с вами команда ITSM 365. Мы собрали для вас рекомендации, следуя которым вы гарантированно превратите вашу сервисную систему в источник ужаса для бизнеса и пользователей. Пойдемте читать и бояться вместе.

Митапы про микросервисы, хайп вокруг новых фреймворков, кеш и перекрашенные кнопки — привычная рутина современного айтишника…

Но мы-то знаем: есть и другое IT. Там пишут код, от которого зависят тонны синтетических материалов или выплавленной стали, скорость производственной линии и бесперебойная работа энергосети. Это мир Heavy Digital. И он становится всё больше.

Мы захотели выяснить, почему всё больше IT-специалистов осознанно выбрали работу на заводах и в промышленных гигантах. Что за мотивы ими движут, какие задачи вызывают настоящий драйв и чувство сопричастности к чему-то большому? Мы собрали эти и другие вопросы и приглашаем всех причастных к IT в промышленности ответить на них в ветке «Я эксперт в Heavy Digital».

А ещё мы хотим узнать мнение тех, кто слышал о Heavy Digital и только стоит на пороге выбора. Чтобы понять ваши ожидания и страхи, мы создали ветку опроса «Я пока не в Heavy Digital».

Спойлер: в конце ветки для экспертов у вас будет возможность рассказать о самом запоминающемся профессиональном вызове. Авторы 10 лучших историй смогут получить ачивку «Герой Heavy Digital» в своем профиле на Хабре.

Готовы? Тогда выбирайте свою ветку — и вперёд!

Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем. Как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.

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

Рассмотрим эффект применения этого инструмента с разных ракурсов.

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

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

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

Это вторая часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой (прочитать можно здесь) мы говорили о платформенности и архитектуре — о том, на чём держится система.

А сегодня расскажем о базе, о функционале классической BI-системы, который и делает систему BI-системой.

Этот раздел про то, без чего не обходится ни одна зрелая BI-система — визуализации, переменные, геоаналитика, сводные таблицы и внутренний язык. Мы не столько гордимся самим фактом их наличия — всё это действительно есть во многих решениях, сколько тем, как именно эти возможности реализованы в Luxms BI — у нас всё заточено под скорость, гибкость и удобство.

Язык Archimate часто используется для описания слоя приложений, функциональности информационных систем и интеграционных сценариев между информационными системами. Но в этой статье я хочу рассказать о применении бизнес-слоя в Archimate, а именно — как описать бизнес-процессы на языке Archimate.

Автоматизацией процессов первым занялся Фредерик Тейлор в начале 1920-х — он это делал в железе и жестко хардкодил, гибкость не была предусмотрена. Но то были производственные процессы, приставку ‘бизнес-‘ к ним еще не приделали.

Логично было применить его метод и к офисной работе, но это произошло гораздо позже — когда началась эпоха персоналок и локальных сетей, во второй половине 1980-х. Тогда и заговорили о «маршрутизации задач» между исполнителями.

Итак, давайте посмотрим, как с течением времени менялись рыночные ярлыки для систем управления процессами...

Привет, Хабр. Это дайджест по ИТ-архитектуре: системный дизайн и практики от Kafka/gRPC и RabbitMQ до наблюдаемости на Prometheus/Grafana, PostgreSQL HA (Patroni+etcd), TOGAF 10/ArchiMate, CQRS/Event Sourcing, Cassandra и Kubernetes/Nomad. Внутри — актуальные программы повышения квалификации и приглашения на бесплатные открытые уроки от действующих практиков.