В теме 7 ответов, и 5 участников, последнее обновление сделано пользователем 
Michaj 12 г, 10 мес. назад.
Показано 8 ответов - от 1 до 8 (всего 8)
-
Сообщения
-
В данной статье мы остановимся на особенностях создания корректных схем бизнес-процессов. Неопытные бизнес-аналитики или просто специалисты подразделений, привлеченные к работам по описанию процессов, подчас «рисуют» такие схемы, которые никуда не годятся. Как этого избежать? Конечно, только после получения нужной квалификации и опыта качество графических схем становится более или менее приемлемым. Но есть несколько аспектов, учет которых позволит даже неопытным в части описания процессов сотрудникам разрабатывать схемы приемлемого качества. Рассмотрим эти аспекты.
Далее: http://analyst.by/news/correctbusinessprocessdescription
Набрел на эту статью с советами по описанию бизнес-процессов.
Первым желанием было написание большого коммента с указанием неправильности этих советов.
Второе желание — выяснить, кому интересно обсудить тему о правильном описании бизнес-процессов. Это вопрос.Набрел на эту статью с советами по описанию бизнес-процессов.
Первым желанием было написание большого коммента с указанием неправильности этих советов.
Второе желание — выяснить, кому интересно обсудить тему о правильном описании бизнес-процессов. Это вопрос.Я думаю, это интересно всем, кто имеет хоть какое-то отношение к бизнес-процессам.
Андрей, я предлагаю тебе написать статью с указанием, с какими из советов ты не согласен, почему и как предлагаешь переформулировать совет.
Что скажешь? (:Я лично с этими диаграммами замучился. Специально зашел на сайт, чтобы наконец поспрашивать людей, прояснить что-н. А тут как раз подходящая статейка обсуждается. Правда статью я уже когда-то читал, и как обычно, все понял… Но как начинаешь практически рисовать — ни бум-бум … Потому что когда читаешь про UML, вроде все понятно, но рисуешь всегда в конкретной программе, и тут оказывается, что прога не позволяет сделать так, как представлял себе, читая теорию. Но тогда приходится предполагать, что ничего не понял в теории, ведь авторы специальных прог, уж наверняка UML знают лучше … Нельзя ли сделать от данной темы некое практическое ответвление? Я бы создал в разделе "Инструментарий и средства, используемые в процессе бизнес-анализа" топик, где на примере маленькой, но в меру реальной задачи, позадавал вопросы в контексте Sparx (по нему совершенно нет мануалов на русском). Мне кажется, есть достаточно много людей, которые борются аналогично мне с этим в одиночку, наверняка им всем подобный разговор был бы интересен.Поддерживаю, только дополню немного: не один топик, а по отдельному топику для каждого кейса. Так проще найти будет.
И еще есть у меня мысль: как насчет написать статью-другую на тему моделирования в Sparx EA (как это есть у нас по Axure)? Есть желающие?Ася, а что конкретно ты там хочешь увидеть? Общий обзор функций уже частично есть в статьях о новых версиях EA, которые мы раньше постили.Я представляла себе что-то вроде туториала, по которому, с одной стороны, можно сообразить, как и что делать в EA, а с другой — разобраться в UML. Как у нас сделано про Axure в этой статье.
Например, "Рисуем диаграмму классов вместе с Герой на примере [название проекта]".
Это было бы вообще супер — туториал. И по каждому инструменту отдельно на сайте аналитиков — сам Бог велел. Но по настоящему полезный туториал — это слишком грандиозная вещь, а краткий обзор совсем начального уровня в нете найти можно. Интересуют-то как раз такие элементарные вещи, которые предваряют достаточно продвинутые возможности. Которые не упоминаются в информации для профи, потому что представляются авторам и так совершенно очевидными, а в информации для новичков, потому что к темам начального уровня не имеют отношения. Интересует выход на построение связанных диаграмм различного вида, трассировку, декомпозицию. Обо всем этом уже неоднократно читано, но как оно практически реализуется (как оно должно выглядеть) в данном инструменте, совершенно не понятно (не известно). Я бы мог предложить в качестве примера свою совершенно реальную небольшую задачку (фрагмент из пары достаточно типично, и в то же време, немножко специфически, взаимодействующих документов). Цель, — отобразить их в ракурсе Domain model так, чтобы потенциально их можно было бы и декомпозировать, и наоборот включить в диаграмму более высокого уровеня, и чтобы можно было связать с другими структурными и динамическими диаграмами. А в идеале, — чтобы Sparx все это мог контролировать на логическую целостность (= правильность понимания и применения UML (при отсутствии человеческой критики, это выход)) …
Показано 8 ответов - от 1 до 8 (всего 8)
Вы должны авторизироваться для ответа в этой теме.
