Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: kris от 24 Декабря 2007, 15:16:41
-
День добрый. Вопрос идиотский есть, решил у Вас спросить :-[. Около 2х месяцев назад поставили передо мной задачу по необходимости описания бизнес процессов деятельности штатного отделения одного из медицинских учреждений. Была оговорена цель моделирования, необходимая точка зрения и требуемые границы модели, а также конкретный субъект описания. Решил попробовать сделать по методичке от Золотухиной (скачал у Вас с сайта). Согласно ее рекомендациям, иерархия пакетов бизнес сущностей должна повторять соответствующую иерархию пакетов бизнес процессов (бизнес сущности моделируются в разбивке по бизнес процессам). Однако при построении иерархии бизнес процессов так получилось, что один и тотже object из колонки входной/выходной информации диаграммы потока работ упоминается в разных пакетах одновременно. Получается, что и при разработке моделей бизнес сущностей данный object также должен фигурировать в разных пакетах? Я планирую описать конкретный object только в одном пакете, а в остальные просто ссылки покидать на него. Так можно? В методичке это не упоминается, там конкретный пакет содержит только уникальные для него объекты.
-
Имхо - вполне можно. Главное, чтобы все товарищи, использующие Вашу модель, понимали принцип ее построения - одинаково.
-
Присоединяюсь к Irr и хочу от себя добавить.
В ходе моделирования у Вас появляется потребность использовать один и тот же объект в разных пакетах. Вы порождаете объект в одном пакете, а вдругом ссылаетесь на него. А таких ссылок может быть немало. Следовательно, можно общие объекты сгруппировать в некотором одном пакете: "Общие сущности", например. Тогда в каждом пакете будут содержаться только объекты внутренние для данного пакета + ссылки на объекты общего назначения.
Скажем История болезни может заводится в процессе Зарегистрировать больного, в процессе Назначить лечение разные врачи вносят туда изменения и т.п.
Советую посмотреть книгку Нейбурга и Максимчука Применение UML в проектировании баз данных (как-то так называется). Там есть сквозной пример как раз про медицинское учреждение.
-
Имхо - вполне можно. Главное, чтобы все товарищи, использующие Вашу модель, понимали принцип ее построения - одинаково.
Спасибо за мнение :) Только вот Ваш ответ заставил меня еще раз подумать о наболевшем... Почему UML не имеет четкой, исчерпывающе описанной методики описания бизнес процессов? Да, есть RUP, в пределах которого имеется некоторое описание методики описания бизнес-процессов, однако реализация строго в пределах данной методики может не позволить ответить на некоторые типы задач и целей, которые ставятся изначально перед бизнес аналитиком. Более того, само case Rational Rose не поддерживает четких синтаксических правил и соглашений. Возможно, в пределах моего круга лиц и будут понимать сделанную мной условность и допущение, но если я захочу со временем продемонстрировать модель лицам "со стороны"? Поймут ли они меня? Мне кажется, что в работах такого рода использование "ИМХО" просто недопустимо. Должны быть четкие правила и следования им. :)
Присоединяюсь к Irr и хочу от себя добавить.
В ходе моделирования у Вас появляется потребность использовать один и тот же объект в разных пакетах. Вы порождаете объект в одном пакете, а вдругом ссылаетесь на него. А таких ссылок может быть немало. Следовательно, можно общие объекты сгруппировать в некотором одном пакете: "Общие сущности", например. Советую посмотреть книгку Нейбурга и Максимчука Применение UML в проектировании баз данных (как-то так называется). Там есть сквозной пример как раз про медицинское учреждение.
Спасибо. Идея с общим пакетом вполне осмысленна и логична.
-
Потому что насколько я понимаю, изначально UML совершенно не заточен под бизнес-процессы, это изобретение архитекторов для разработчиков для описания внутренностей систем силами объекто-ориентированного анализа.
Для описания бизнес-процессов создавались нотация, используемая в Aris и BPMN.
Риск непонимания есть всегда. Если на этом форуме идет обсуждение, что есть Usecase, функция или сценарий использования, о каких единых правилах может идти речь?
Мы живем в эпоху апокрифов и религиозных столкновений, сейчас нет одной единственной истины на всех. И ни UML, ни Золотухина не осветят нам единственный правильный путь! Делай раз, делай два - не выйдет, все время приходится дуууууумать!
Ой, Остапа понесло...
-
Да, UML изначально создавался для решения задач другого характера, однако в настоящее время он (точнее, Rational Rose) активно предлагается и рекламируется и для решения задач по бизнес моделированию. Что до "думать", то это делать надо всегда и при решении задач любого характера ::). В All Fusion Process Modeler думать тоже часто приходится... :) Идея в том, что если каждый бизнес аналитик, работая с UML, будеть так вот "думать", то смогут ли они правильно понять сделанные друг другом модели?
-
UML и Rational Rose по-моему сильно разные вещи, одно нотация моделирования, другое продукт, это как теплое и мягкое. Да, IBM большая фирма, которая может широко рекламировать свои продукты, но это не значит, что у них есть единый на всех учебник, в котором все написано. Кстати, если сравнивать RUP как точку зрения IBM на бизнес-моделирование и курс Золотухиной - это таки тоже разные вещи :-) Нет пророка в этом мире!
Приходится смиряться, рисовать методику моделирования и быть готовым к критике своих моделей.
У меня единственная надежда в этом смысле на BPMN: если оттуда возможна трансформация в исполняемые процессы, то там все-таки намного строже все. И валидаторы есть. Но информации по тому же BPMN достаточно мало, в результате опять каждый может придумывать свой вариант...
-
Вот тут недавно перечитывал свой пост, много дельных мыслей в нем высказано:
http://www.uml2.ru/forum/index.php?topic=71.0
Единственное, что можно сказать, что все приходит с опытом, сначала Вы метаетесь в поисках лучшего, а потом просто делаете, т.к. знаете что это правильно, т.е. модель адекватна.
А вообще сейчас моден Агиле, кот. говорит - минимум артефактов, максимум коммуникаций. Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.
З.Ы. А вообще, Золотухина далеко не истина в последней инстанции.
-
Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.
Саша, хочу, хочу. Сделай мне подарок на Новый год, а? Отскань главку :)
Irrунь, ты прям трибун.
Вообще, у меня есть такое желание что-то написать, типа: "Назад в будущее UML или "бизнес" - это мы не проходили!".
IDEF0, делает ставку на минимализм средств отображения. Фишкой, кажется, считается строгость нотации и наличие разных видов входов: собственно вход-сырье, вход-управление, вход-механизм. Строгость и сила, и слабость. Возникает потребность искуственной декомпозиции, иногда сложно разделить управление и вход, плохо согласуется с ОО
IDEF3, как мне, кажется, используется редко и часто совершенно неверно. Думаю, связано с тем, что появились более приемлемые решения в виде диаграмм видов деятельности и им подобным. Представитель направления workflow
DFD - интересная нотация, активно поддерживается до сих пор, однако кроме Калянова даже и не знаю, кто использует для описание бизнес-процессов
ARIS- штука интересная, но мною не изучалась глубоко. Однако, MS пытается сделать ее стандартом, что может иметь большие последствия
Расширения UML Эриксона-Пенкера, хороший переход от IDEF0 к использованию инструментов c UML. Наверное именно так и задумывался, поскольку сами авторы утверждают - никаких новых идей, никаких новых подходов. Business Modeling with UML: Business Patterns at Work by Hans-Erik Eriksson and Magnus Penker ISBN: 0471295515 John Wiley & Sons © 2000 (459 pages). Опять же кроме как в Enterprise Architect больше и не встречал
BPMN - насчитывает 3 года торжественного шествия, часто реализуется в UML tools, в той или иной степени строгости. При этом явно утверждают - мы лишь язык описаний ничего большего, все правила использования полностью на отвественности автора. Регламентируется лишь стадия перехода от BPMN к конструкциям BPEL, по-моему. А это уже фактически программирование, тут без строгости не обойтись. Сам язык, не что иное как таже диаграмма активности, IDEF3, немного ARIS, чуточку IDEF0 в одном флаконе. Фишка - развитый набор событий и логических переходов, но опять же весь этот набор так специфичен и на уровне описание бизнес-модели, как мне думается, опасен к использованию.
Кто продолжит :)?
-
В общем, в каждой избушке свои погремушки.
А мы, бедные, медитируем и пытаемся по коанам познать истинное Дао. Только монахам обычно легче, там учитель рядом, а не книги на иностранных языках или в не всегда корректных переводах
-
UML и Rational Rose по-моему сильно разные вещи, одно нотация моделирования, другое продукт, это как теплое и мягкое.
Железно, с этим трудно не согласиться. В целом, направление Ваших мыслей мне вполне понятно, хотя и не могу сказать, что полностью с ними согласен.
Кстати, а есть где-нибудь описание методики бизнес моделирования по RUP на русском языке? Пока-что видел и читал только на оригинальном...
-
Кстати, а есть где-нибудь описание методики бизнес моделирования по RUP на русском языке? Пока-что видел и читал только на оригинальном...
Дык нет в свободном доступе перевода RUP на русский язык. По-моему, за деньги такое делал CMConsult с Новичковым, но результатов я не видела.
-
А перевод того же Новичкова части книги Введение в RUP от Кратчена? По моему где в нашем архиве есть
-
А перевод того же Новичкова части книги Введение в RUP от Кратчена? По моему где в нашем архиве есть
Есть, но он не сильно помогает постичь истинное Дао. Вопросы-то по правилам и логике использования конкретных элементов, т.е. более касаются моделирования. А введение в RUP - это все-таки общие слова, а не UML, не глубже, чем декларация политики партии. Хотя конечно лучше прочитать и введение :-)
-
Чтобы постичь кун-фу, нужен долгий путь совершенства. Практика - основа движения по пути.
В общем надо просто больше моделировать, обсуждать модели на форумах и с друзьями. Стараться моделировать задачи из разных областей. С ростом количественных признаков порождаются качественные. Насколько я помню Гегель установил
-
Я согласен с Арамисом! (c)
Гегель, он самый.
-
Дык нет в свободном доступе перевода RUP на русский язык.
Ну, на одном сайте видел я на русском очень краткое описание самой сути бизнес моделирования по RUP.
Кстати, если у кого есть желание, могу отослать на почту для просмотра и критики ту модель, которая у меня сейчас получается. Она, конечно, далеко не закончена, однако что-то уже есть (с Вас адрес почты).
-
galiaskarov злой собака isuct офигенная точка ru
-
galiaskarov злой собака isuct офигенная точка ru
Какой злой адрес:). Ушло.
-
Замечательным примером того, как по одним и тем же словам возникают разные диаграммы классов, является вот эта ветка: http://www.uml2.ru/forum/index.php?topic=560
Так о каких единых правилах может идти речь?
Кстати, может и Вашу модель выложить в примеры? Тогда к обсуждению возможно присоединится не только уважаемый Аксакал
-
ой там моделище, а не моделька, думаю вряд ли у почтенного общества хватит желания усе там проверять и понимать
-
ой там моделище, а не моделька, думаю вряд ли у почтенного общества хватит желания усе там проверять и понимать
Да нет. Все еще впереди. Над ней работать и работать мне еще.
-
The Russian Programmers
A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.
I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain."
After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.
In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.
The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across.
The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1998) refers to this as "reducing the equivocality" in the communication.
What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action.
Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.
The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to can help the receivers to jump larger gaps.
Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there.
-
Перевод в Промт 8 со стандартными словарями
Российские Программисты
Группа в американской фирме, которая заключала их программирование к российской компании, вошла в контакт со мной. Они хотели, чтобы я преподавал им, как написать случаи использования для российских программистов, которые не знали ни английского языка, ни домена очень хорошо.
Я сказал, "Вы не можете надеяться преподавать им домен в документе требований. Сначала преподавайте им домен, затем напишите короткий документ требований, который говорит с кем-то хорошо осведомленным в домене."
После попытки в течение многих часов, чтобы заставить меня раскрывать тайну сообщения через этот огромный промежуток, они наконец признали, что они имели ранее (и успешно) работавший просто, помещая ключевых людей в тот же самый участок памяти. Они только надеялись, что у меня был способ сообщить требования через океан, отлично используя случаи использования.
В конец они изменяли к лучшему мое предложение. Они написали короткий документ требований для их местных специалистов по проблемной области и затем доставили одного из тех экспертов в Россию, чтобы перевести, объяснить, и вообще гарантировать, что программисты делали правую вещь.
Специалист по проблемной области мог перейти большой промежуток, представленный в соответствии с коротким документом случая использования, и затем произвести, столь же необходимый, и только как необходимо, коммуникация, чтобы заполнить и сократить размер промежутков так, чтобы российские программисты могли перейти через.
Специалист по проблемной области не пытался общаться отлично. Он управлял непрерывной неполнотой связи, взаимодействуя с программистами лично и смотря, что они произвели. Luke Hohmann (1998) именует это как "сокращение двусмысленности" в коммуникации.
То, что понял специалист по проблемной области, было то, что он не должен был уменьшить двусмысленность, чтобы обнулить. Он только должен был уменьшить это к сути, что российские программисты могли предпринять значимое действие.
Учитывая, что законченная коммуникация никогда не возможна, задача на проекте не состоит в том, чтобы попробовать за законченную коммуникацию, но управлять неполнотой нашей связи.
Адресат должен уменьшить двусмысленность достаточно для соответствующего действия, которое будет предпринято. Это означает предполагать, сколько необходимо, где остановиться, когда и как сделать меньшие промежутки, и как к может помочь получателям переходить большие промежутки.
Программные проекты - короткое замыкание вовремя и деньги, и создание промежутка меньшая стоимость оба. Вы должны обнаружить, как большой промежуток, с которым Вы можете пройти в каждый момент, сколько двусмысленности Вы можете терпеть, и остановить там.
Ничего не понял :)
-
Ничего не понял :)
Я всё жду - не дождусь, когда же появятся переводчики на базе нейросистем. ИМХО, технически уже вполне реализуемо.
-
Ничего не понял :)
Эд, а ты всегда так читаешь англоязычную лит-ру??
-
Саш, да нет. Я почему и прибег к помощи переводчика. Прочитал раз, прочитал два. Не фига не понял чего там автор пытается сказать.
Все у него кто-то там прыгает бегает, через что-то перескакивает, а до чего доскакались так и не понял. Запустил промт, вроде перевод ну относительно гладкий, а смысл ускользает.
Идея вроде понятная, но что пытается объяснить автор? Толи что русские нетерпеливые, плохо знают предметную область, либо пытаються все сразу описать, вместо того, чтобы дать краткое содержание, которое постепенно уточнять.
Поясни что ты сам понял?
-
Эд,
Ну да одна под-глава не даст полного представления о том, что хотел сказать Коберн.
Всю главу можно прочесть здесь: http://alistair.cockburn.us/index.php/ASD_book_extract:_%22Unknowable_and_incommunicable%22
Просто до этого он рассказывает о том, что два человека, имеющих разный бэк-граунд, могут понять одни и то же предложение по разному. Поэтому, прежде чем начать разработку, надо всех участников погрузить в "domain", т.е. объяснить/рассказать предметную область. И чем ближе и дольше люди общаются, тем им меньше надо что-то писать, достаточно только сделать мазки, чтобы не забыть через месяц о чем кто-то хотел сказать.
И как раз мастерство аналитика - это:
"You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there."
"Вам надо понять - на сколько большие разрывы/шаги вы можете сделать в каждый конкретный момент, как много неоднозначности Вы можете допустить, и остановиться здесь"
Тут русские не причём, просто Коберн хотел показать, что для людей с другой культурой и без знания ПрОбл не возможно все описать, все равно будут недопонимания и двусмысленность.
-
Дык нет в свободном доступе перевода RUP на русский язык. По-моему, за деньги такое делал CMConsult с Новичковым, но результатов я не видела.
Не надо путать Александра Новичкова и Новикова Леонида Борисовича. Это разные люди, с радикально разными экспертизами. Объединяет их только то, что оба работали в Интерфейсе когда-то.
Новчиков и его компания СМ-Консалт предлагает только ТРЕНИНГИ для подготовке к сертификации по инструментарию ClearCase, ClearQuest. А вот Новиков Л. Б. действительно занимался переводом RUP на русский. Официальная позиция в то время компании Rational была в неодобрении локализаций RUP. Лично я не вижу большего смысла в переводе, если честно.
-
Юрий, информацию, которую я выдала в цитированном сообщении, я узнала лично от Александра Новичкова на одном из его тренингов, и я не путаю фамилии. А переводить RUP может больше чем один человек на всю страну.
-
Юрий, информацию, которую я выдала в цитированном сообщении, я узнала лично от Александра Новичкова на одном из его тренингов, и я не путаю фамилии. А переводить RUP может больше чем один человек на всю страну.
ОК, завтра у него узнаю, что он имел ввиду :-).
-
ОК, завтра у него узнаю, что он имел ввиду :-).
Отлично, мне ужасно интересно, были это переводы отдельных кусков под конкретную организацию, оплатившую перевод, или полный перевод.
-
Отлично, мне ужасно интересно, были это переводы отдельных кусков под конкретную организацию, оплатившую перевод, или полный перевод.
Перевод был сделан "под конкретную организацию и конкретной версии"
-
Перевод был сделан "под конкретную организацию и конкретной версии"
Если нельзя, но очень хочется, то можно :-)
-
<...>Около 2х месяцев назад поставили передо мной задачу по необходимости описания бизнес процессов деятельности штатного отделения одного из медицинских учреждений. Была оговорена цель моделирования, необходимая точка зрения и требуемые границы модели, а также конкретный субъект описания. Решил попробовать сделать по методичке от Золотухиной (скачал у Вас с сайта). Согласно ее рекомендациям, иерархия пакетов бизнес сущностей должна повторять соответствующую иерархию пакетов бизнес процессов (бизнес сущности моделируются в разбивке по бизнес процессам). Однако при построении иерархии бизнес процессов так получилось, что один и тотже object из колонки входной/выходной информации диаграммы потока работ упоминается в разных пакетах одновременно. Получается, что и при разработке моделей бизнес сущностей данный object также должен фигурировать в разных пакетах? Я планирую описать конкретный object только в одном пакете, а в остальные просто ссылки покидать на него. Так можно? В методичке это не упоминается, там конкретный пакет содержит только уникальные для него объекты.
Так вполне можно. Правда, мой практический опыт основывается только на курсовой, который Елена Болеславовна нам в своё время давала в качестве курсовой.
Лично мне не нравится применять UML для моделирования бизнес-процессов. Может, потому, что Скворцов читал нам моделирование бизнес-процессов при помощи ARIS уже после того, как Золотухина читала то же самое при помощи UML.
Советую Вам использовать если не ARIS Toolset, то хотя бы Visio, чтобы смоделировать Ваши бизнес-процессы с помощью моделей в нотациях ARIS VAD, eEPC, Organizational Chart, ERD.
-
AlexTheRaven, рад видеть Вас снова с нами.
Не могли бы Вы рассказать чуть больше, чем методика Золотухиной Вам не подошла, или оказалась хуже методики ARIS.
Так же интересно, что Вы думаете об использовании BPMN. Правда, следует сказать, что BPMN не предлагает новых методик, а просто иную нотацию. Как я понимаю, BPMN можно использовать и в рамках методики Золотухиной, и ARIS, и других
-
Я тоже рад, что вроде бы "переварил" задачи, которые на меня упали, и у меня освободились некоторые временнЫе ресурсы и вычислительные мощности для обмена опытом :) .
У Золотухиной - вполне работоспособная методология, но мне НЕ нравится использовать UML для описания бизнес-процессов. Activity, Sequence и Collaboration не имеют такой выразительности, как eEPC. Действительно, при помощи собственных стереотипов экземпляров и связей можно показать всё то же самое, но удобство не то: в ARIS eEPC, по сути, все необходимые стереотипы уже введены, исполнителей можно показывать не только с помощью swimlanes.
Опять же, ARIS Toolset как инструмент значительно удобнее CASE-средств, специализированных для UML, имеет модули Simulation, ABC, BSC и др. В UML CASE-средстве создаётся схема БП, а в ARIS - визуальное изображение мат. модели БП, готовое к мат. анализу и имитационному моделированию.
-
Alex, Вас понял. С этой точки зрения возможно еще интереснее System Architect от Telelogic. Кажется и по стоимости они равняются. Правда там упор бизнес-анализа сделан на использование SADT или BPMN. Есть средства моделирования процессов.
Кстати моделирование процессов с созданием модели есть и в Together Designer 2006 R2, по сути создаем нечто вроде СМО и моделируем.
-
В UML CASE-средстве создаётся схема БП, а в ARIS - визуальное изображение мат. модели БП, готовое к мат. анализу и имитационному моделированию.
А хто этим пользуется??
-
IDEF0,
IDEF3,
DFD -
ARIS-
Расширения UML Эриксона-Пенкера,
BPMN -
Кто продолжит :)?
только вчера дали шаблон типа для оформления результатов бизнес-анализа.
так там притянули ещё и
"Методику построения диаграммы Исикавы-Сибирякова для анализа нетехнических систем"
шо за зверь такой, может, кто пользовался?
-
Причинноследственная диаграмма (рыбья кость)
http://www.mael.ru/Rus%20ver/Metodicheskie_posobija/Economisti/4/Schevirev_Speckurs.doc
это от яндекса http://www.yandex.ru/yandsearch?clid=9582&text=%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0+%D0%98%D1%81%D0%B8%D0%BA%D0%B0%D0%B2%D1%8B-%D0%A1%D0%B8%D0%B1%D0%B8%D1%80%D1%8F%D0%BA%D0%BE%D0%B2%D0%B0
и если потом еще посмотреть на картинки!
(http://www.cfin.ru/forum/messages/2857/40517.jpg)
-
А хто этим пользуется??
За рубежом - крупные промышленные компании, особенно машиностроительные. Для этих компаний экономия центов, минут и сотых процента вероятности брака на одной операции может дать миллионы долларов в год и, следовательно, конкурентное преимущество.
У нас же с конкурентами всё ещё чаще "соревнуются" административным ресурсом и недружественными поглощениями, а не повышением эффективности бизнес-процессов. Потому что первичное накопление капитала, знаете ли. Мне известно об использовании имитационного моделирования в компаниях, управляющих аэропортами и атомной промышленностью - скорее для борьбы с беспорядком и несогласованностью, которые могут стоить таким компаниям очень дорого.
-
Т.е. в России таких примеров нет. Фуф, а то я подумал, что отстал от жизни :) Просто теоретически можно использовать все что угодно, а на практике оказывается совсем другое. И вообще оптимизация БП это отдельная большая тема, по которой следовало бы сделать семинар. И, как говорится, АРИС тут только помощник, а методику никто толком не знает.
Кстати вопрос был хороший:
"что Вы думаете об использовании BPMN", в замен АРИС.
-
<...>И вообще оптимизация БП это отдельная большая тема, по которой следовало бы сделать семинар. И, как говорится, АРИС тут только помощник, а методику никто толком не знает.
Почему же нет? Мы просто можем о них не знать.
Почему же - никто не знает? Первое, что приходит в голову - правила Хаммера, индикаторы, поиск "бутылочных горлышек".
Кстати вопрос был хороший:
"что Вы думаете об использовании BPMN", в замен АРИС.
IMHO - вопрос из серии "что лучше использовать, катакану или хирагану?". При этом кандзи понимания сути процессов должна быть в любом случае.
-
К вопросу о моделировании.
Поскольку здесь затрагивается вопрос математического моделирования, а не какого-то другого, то могу сказать, что имею опыт моделирования систем. Математическое моделирование распадается на аналитическое и имитационное, еще можно добавить комбинирование.
Довольно часто бизнес-процессы сводят к математическим моделям систем массового обслуживания или гибридных автоматов.
Лично я имею опыт моделирования СМО. С этими целями могут быть использованы:
1. GPSS - general purpose system simulation - интересный язык, не визуальный
2. Object GPSS - не щупал слишком дорогое удовольствие
3. Arena - система имитационного моделирования бизнес-процессов . Система нотаций чем-то очень напоминает ARIS, тесно интегрирована c BPWin через сценарии IDEF3. Моделирование основано на CMO, штука богатая и сложная
4. Simulink который входит в Matlab. Потрясная визуальная штука. Стоит дорого. Можно моделировать разные штуки.
5. SimEvents - входит в Simulink моделирует дискретно-событийные системы на базе СМО
6. System Architect - встроенная система моделирования на базе моделей IDEF3
7. Together Designer 2006 R2 и выше - встроенная система моделирования процессов на базе BPMN
8. Сети Петри и модификации
9. NetWork в пакете Statictics, Matlab
10. Просто решение систем дифуров в различных пакетах