Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.
EDI стандарт. Технический обзор
Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.
User
Я создаю IT-курсы уже 6 лет, являюсь руководителем направления обучения Бэкенд-разработке в онлайн-школе и даже развиваю свои собственные курсы по программированию на Python. Еще веду корпоративные обучения, работаю в универе и провожу консультации о построении пути в IT.
И как бы это не выглядело саморекламой, я хочу сказать, что очень много работаю с людьми, которые пытаются начать свой путь в IT, топчутся на месте, не понимают куда двигаться, учатся по четыре года или вовсе бросают, и спустя несколько лет даже могу систематизировать все их проблемы на несколько типичных категорий. Об этом я уже написала кучу постов и даже сняла пару вебинаров, как и еще сотни специалистов и блогеров, поэтому не хочу повторяться. И повторять миллионы статей о построении пути, как стать разработчиком или роад-мепы я тоже не буду.
Я не буду говорить как выстроить путь, какой язык вам лучше выбрать и какие ошибки не совершать.
Я хочу дать несколько советов, которые помогут вам этот путь не забросить. И разобрать самые типичные проблемы, с которыми сталкиваются многие люди.
Иногда приходится сталкиваться с мнением, что «нет проблем пойти и узнать, чего хочет бизнес». Проблем нет. Есть навыки, которые нужны как и в любом другом деле. Хочу показать несколько типичных ошибок, которые бывают очень заметны. Такие ошибки могут сделать бесполезной работу по выявлению требований, а заодно и всей команды, которая будет работать работать по этим требованиям.
Привет, Хабр! В продолжении темы, связанной с внедрением Каталога ИТ-услуг в компании, хочу разобрать достаточно популярный вопрос (не знаю, как у других, но у нас так точно) – зачем нужно возиться с услугами, если все пользователи работают с системами? Логичнее же «идти от систем», чем каких-то «никому не понятных услуг». Давайте разбираться и взвешивать все «за» и «против». Пусть каждый сам для себя решит, как эффективно выстроить процесс управления ИТ в общем и, взаимодействие с бизнесом, в частности.
Начинаю серию статей, посвященных задачам аналитика на различных этапах создания программного обеспечения (ПО). В ходе наших бесед, мы рассмотрим, какие конкретные артефакты возникают после завершения каждого этапа, а также как правильно составлять эти артефакты.
— Что работодатели хотят от джуниор аналитика данных?
— Работодатели хотят, чтобы он был мидлом.
Если ты не смеёшься над этим анекдотом, то наверняка недавно закончил (либо заканчиваешь) обучение по обретению специальности «Аналитик данных». А ещё ты пока не нашел, но уже начал искать свою первую работу. Меня зовут Ольга Матушевич, я наставник на курсе «Аналитик данных» в Практикуме. В этой статье я предложу решение проблемы «как получить опыт работы, если без опыта никуда не берут» с помощью самостоятельных проектов.
Данный цикл статей предназначен для всех, кто собирается приступить к созданию моделей с использованием BPMN.
Моделирование бизнес-процессов обычно рассматривают в контексте их оптимизации с целью повысить эффективность бизнеса в компании в целом. Обычно такая потребность возникает, когда в компании имеются проблемы: например, низкая эффективность ее сотрудников, не оптимальная организационная структура, запутанные коммуникации или неправильное разграничение зон ответственности между ее подразделениями могут ограничивать возможности организации, приводить к снижению ее прибыли, сдерживать ее развитие, делать ее менее конкурентоспособной.
Зачем придумали нотации (прим. система условных обозначений, принятая в какой-либо области)? Все просто, они помогают предотвратить много споров и конфликтов между людьми. Давайте посмотрим как BPMN (прим. Business Proccess Modeling Notation) нотация помогла нашим героям.
В некотором царстве, в некотором государстве жил был Царь и была у него мечта создать онлайн школу для обучения своих подданных. Созвал царь ученых со всего мира думу думать и решение предлагать. Три дня и три ночи трудились лучшие умы мира над решением задачи и вот предложили свое решение царю. И вот беда, Царь не понимает решений, один на иностранном языке все описал, другой непонятными символами. И говорит Царь: "Нет, братцы, так дело не пойдет, давайте-ка вы на одном языке мне все нарисуете, тогда я смогу выбрать лучшее решение!"
Царь предложил систему условных обозначений (нотацию bpmn) и обучил ученых как ей пользоваться.
Схемы по методу моделирования бизнес-процессов (BPMN) используются в разных сферах, например, в продажах и ведении проектов. В разработке этот инструмент важен на этапе бизнес-аналитики: с помощью BPMN описываются все сценарии взаимодействия пользователей и системы. Такие диаграммы создавалась специально для того, чтобы найти общий язык между аналитиками и управленцами без технической подготовки.
В названии цифра «2» не из-за версии нотации (хотя она и так 2.0), а потому что это вторая статья. В первой я рассказывал про наш путь к Activiti и о том, почему от этого инструмента стоило отказаться и идти дальше. И сегодня я расскажу, куда же мы пошли.
На сегодняшний день BPMN является одним из самых распространенных методов описания бизнес-процессов, которые сегодня уже «понятны» как бизнес-пользователям, так и программным продуктам, предназначенным для работы с бизнес-моделями. Т.е. этот язык описания также является стандартом для создания исполняемых алгоритмов в управлении бизнесом.
О том, что такое BPMN, написано много. Но практически вся информация, которую можно найти в Интернете, ориентирована на специалистов, которые ранее сталкивались с BPMN или другим стандартом моделирования бизнес-процессов. Предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она все чаще используется для описания бизнес-процессов организации.
Методология моделирования бизнес-процессов — очень широкое понятие, по сути, это та самая база знаний, которую необходимо для практического применения языков моделирования бизнес-процессов. Я расскажу об этом в следующих статьях и не раз. Почему я акцентирую на этом внимание? Многие (и я в том числе) считают, что достаточно выучить язык бизнес-моделирования, и вы сможете строить бизнес-процессы.
Практика показывает, что базовые знания методологии моделирования бизнес-процессов здесь незаменимы. Перед тем как изучать моделирование, для начала необходимо ознакомиться с методологией бизнес-моделирования, понять общие принципы, приобрести определенные навыки бизнес-анализа и только потом приступать к изучению нотации BPMN.
Или ментальные «ловушки», которые мешают аналитикам использовать нотации.
От системного аналитика требуют знание нотации BPMN (Business Process Model and Notation). Недавно среди своих коллег — системных аналитиков — я провела опрос о BPMN. Мне было интересно узнать используют ли мои коллеги нотацию, как именно и в чём сложности. В результате я нашла парадокс: большинство коллег считают, что нотации необходимы в работе, но на практике используют меньше половины. Почему возник такой парадокс и как его решить?
Анна Вичугова, CBAP, написала стартовое пособие по тому, как начать моделировать бизнес-процессы в BPMN
1. Назначение BPMN.
2. Уровни моделирования.
3. Алфавит нотации: События, Логические операторы, Артефакты.
4. Правила построения диаграмм.
5. Пример построения диаграммы по тексту.
6. Рекомендуемые инструменты.
Всем привет! Меня зовут Артём Полуян, я руководитель системных аналитиков в SM Lab. В этой статье хочу поделиться одной любопытной статистикой, которую мне удалось собрать за два года.
Что за статистика и откуда она у меня взялась? Дело в том, что у меня есть своего рода хобби: раз в три месяца я провожу тренинг по менторству (наставничеству) для сотрудников нашего департамента системного анализа. За два года я провёл девять таких тренингов, которые посетило суммарно около ста системных аналитиков и аналитиков данных.
На тренинг приходят ребята с самым разным опытом. Кто-то только готовится стать ментором в своей команде, а кто-то, уже имея некоторый опыт, приходит обменяться экспертизой с коллегами. Формат мероприятия больше напоминает дискуссии, в рамках которых определяются оптимальные варианты выхода из различных ситуаций, в которых может оказаться ментор.
На всякий случай обозначу, кто такой ментор в нашем понимании. Ментор — опытный участник команды, который прикрепляется к новому сотруднику (менти) для осуществления онбординга. Тут у нас всё примерно так же, как и в любых современных IT-компаниях.
На реальных кейсах и живых примерах
За последние 5 лет из России уехало 1 250 000 человек. Я — среди них. В 2022 продал всё, что у меня было: дом, машины, бизнес и уехал сначала в Турцию, а потом в Дубай.
Уже 1,5 года шаг за шагом строю новую жизнь и компанию с нуля.
Успел за это время:
✔️ Запустить бизнес в Сингапуре, Польше, Дубае и Грузии.
✔️ Научиться зарабатывать по $500 в месяц с каждой мини кофейни и по $5000 c 10. В России на том же бизнесе получалось $380 / $3800.
✔️ Родить дочку).
Привет, Хабр! Хочу рассказать вам сегодня об одном инструменте. Он помог мне когда-то понять как устроены сложные организационные системы, как с ними работать, и самое главное, как их менять. Можно сказать, этот инструмент - линза, через призму которой мы можем по-другому посмотреть на окружающий нас мир.
Инструмент называется Айсберг системного мышления, и сегодня поговорим о нем.