Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: Keen_G от 23 Декабря 2006, 23:47:41
-
Вот такой вопрос возник:
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов? Чтобы описать процесс с достаточной степенью подробности даже для каких-нибудь крупных предприятий. Хотелось бы определить именно необходимый минимум диаграмм, а так же степень взаимосвязанности и взаимозависимоти друг от друга.
Ну понятно, что фундаментальные
1. диграмма ВИ, она хорошо подточена под бизнес... без нее не обойтись для описания БП высокого уровня иерархии
2. ДК, тоже считаю обязательным...
А что еще? Возможно диаграмма состояний...
Может быть есть какая-то спец литература, подточенная под бизнес модели... а?
-
Для описания БП можно использовать как подход декларируемый RUP -- BUC/BA models, так и модификации, которые предложены различными авторами, вплоть до введения ими собственных стереотипов. В любом случае, описание бизнеса тоже сводится к описанию статической и диниамической составляющей. Статика - это те же BUC диаграммы и различные вариции на тему диаграмм классов. Динамика это activity/sequence/collaboration.
Тут есть один момент -- он связан в частности с тем, что нужно четко понимать какую цель мы преследуем, когда хотим заняться описанием бизнес-процессов, и подбирвать соответстующие средства для этого. Например, если цель сделать автоматизацию БП, в сфере где БП нам известны, то не факт, что имеет смысл делать полномасштабное описание бизнеса, а может только некоторые общие вещи или наоборот -- отдельные детали. Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.
-
Если рассматривать RUP и RR, то при построении диаграмм вариантов использования есть два средства уточнения или детализирования процесса - это в первую очередь диаграммы деятельности и диаграммы состояний. В большей части используют диаграммы деятельности, которые по существу могут заменяться сценарным описанием либо дополняться им. При этом ДД могут быть несколько на основной поток и на альтернативные действия. Как используются ДС на бизнес уровне, не очень ясно - мало видел примеров.
Далее каждый ВИ может связываться с диаграммой бизнес-объектов, описывающей реализацию. Реализация обычно описывается через диаграммы последовательности и диаграммы взаимодействия, что в общем одно и тоже. При этом каждая операция в данном контексте - есть событие возникающее в ходе реализации ВИ.
Часто на некотором абстрактном уровне строят диаграмму последовательности для случая когда с одной стороны имеем актера, а с другой стороны систему. Это помогает понять какие события возникают между актером и системой. Такая диаграмма без лишней детальности позволяет показать общий контекст и быть простой и одновременно наглядной и информативной
-
Спасибо за посты!
Ну вот передо мной лежит книга "RUP - это легко" (Кролл, Кратчен), должен подметить, что на
примерах бизнес-моделей прохалтурили...
Т.е. с учетом сказанного к такому выводу можно прийти:
Чтобы описать с некоторой минимальной степенью подробности бизнес-процесс, используем:
1. Статика
Бизнес расширения диаграммы вариантов использования + расширения для бизнес-систем диаграммы классов
2. Динамика
Детализируем процессы при помощи диаграммы деятельности
-
Стоп стоп стоп.
Диаграммы последовательности - это тоже динамика. Что есть динамическая система, система изменяющая свое состояние, т.е. имеющее не одно состояние. Когда мы фиксриуем статику (ДВИ или ДК) мы фиксируем устойчивые связи. Когда мы используем ДП, ДВ, ДС, ДД - все это уже поведенческие модели.
Т.е. ДВИ и ДБО показывают разметку, а все остальное, как используя эту разметку из пункта А попасть в пункт Б - варианты будут разные, потому требуют оценки с позиции результативности, ресурсоемкости и эффективности.
Думаю не ошибусь сильно: ДВИ и ДБО дают контекст, в котором нам предстоит работать, задает фазовое пространство. Остальные диаграммы дают описание возможных траекторий. Одна из которых должна быть определена. Чем хорошо UML и некий процесс, он задает правила использования. Так же как скажем определение отношения: декартовое призведение множеств. Но это все варианты, но семантически часть из них незначимы и невозможны...
-
Вот такой вопрос возник:
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?
А почему именно UML, это что, самоцель?
Ну понятно, что фундаментальные
1. диграмма ВИ, она хорошо подточена под бизнес...
Это в каком смысле?
-
2Galogen
Да-да, это все, в принципе, понятно и вполне логично! Хотя я немного склонялся к мысли, что для описания объектно-ориентированных систем и бизнес-процессов должны быть более значительные различия именно в идейной методологии...
2Денис
Да нет никакой цели, только в качестве самообразования... Дело в том, что описание БП по методологии ARIS, даже описание БП в excel в виде перечисления последовательности действий и тп, вполне представляю, даже немного приходилось делать, а вот по UML с трудом... никогда не видел, поэтому и интересно. Что касается вопроса о том какую из методологий лучше использовать, уж не знаю, склоняюсь больше к Арису
-
Keen_G, между тем с помощью UML при введении стереотипов, и картинок, можно легко сделать бизнес-процессы. И даже такие как в ARIS.
Рисовалка и есть рисовалка, важно мне кажется не как изобразить, а можно ли рутину переложить на плече компа и получать либо полуготовый код, либо вполне работающее приложение, либо .. А зачем изучают бизнес процессы??? Ась???
Правда из разговора с коллегами-форумчанами, понял, что мне эти БП вроде и не к чему, и связываться с ними тоже вроде как странно:-))
-
[quote autor=Galogen]между тем с помощью UML при введении стереотипов, и картинок, можно легко сделать бизнес-процессы. И даже такие как в ARIS.[/quote]
Несомненно! ну а толку то :-))
Galogen, есть идеи о том как организовать автоматическое (машинное) построение БП? Очень интересно, но с трудом даже представляю как это может выглядеть... Мегареволюционная идея...
А зачем изучают бизнес процессы???
Сейчас по проекту в довольно крупной организации сижу... И частенько ситуации бывают, когда надо узнать непосредственные обязанности экономистов, бухгалтеров и тд. (Потому что если спрашивать лично человека, то окажется, что у него вообще практически нет обязанностей) А БП выложены на портале, спокойненько смотрю: ага, экономист, делает то и то и то....
-
Keen_G! Гусь свинье не товарищ. Гусь это, конечно, ты, я свинья. Т.е. ты летаешь высоко, сталкиваешься с насущными проблемами. А я? А я каждую задачу высасываю из пальца. Прадва я не очень понимаю зачем усложнять сложное. Т.е. к примеру - разве студенту не посилам понять, хотя бы поверхностно, бизнес-процессы скажем в магазине, или в некотором упрощенном производстве.
А насчет автоматизации - да нет я про другое, у меня вообще ощущение, что все не так, или я не туда попал. Да не работаю я с бизнес-процессами так таковыми. Откуда мне их взять, хотя могу например смоделировать ситуацию по документооборуту кафедры, учебного процесса, системы образования и что-то в этом роде. А бухгалтерия, кадры, делопроизводство, ну откуда я их знаю? Да не откуда мне их знать. Я не учился на экономическом, не изучал юрнауки, социальные науки, науку управления. Я технарь, инженер, ученый если хотите.
В силу случая, стал вот преподавать компьютерные науки. За 6 лет сильно конечно развился, но это мог сделать любой здравомыслящий человек, имеющий интерес.
А когда я говорил про автоматизации рутины, я имел в виду - что инструмент берет на себя проверку логики, органичений, соответствия правилам и т.п. И конечно я впервую голову рассуждаю не о ВЫСОКОМ БИЗНЕС_УРОВНЕ, где находится пласт бизнес аналитиков, а уже более приземленный, где сидит пласт системных аналитиков, специалистов в области программирования, ИТ, баз данных и т.п.
Это называется разделение труда. Правда системных аналитиков как я понимаю мы тоже не готовим :(
-
А когда я говорил про автоматизации рутины, я имел в виду - что инструмент берет на себя проверку логики, органичений, соответствия правилам и т.п.
Думаю, разработчик такой системы озолотится!!! Идея, конечно, классная... Но, на мой взгляд, самые главные проблемы будут даже не в сложности самой системы, способной так "читать" БП, а в универсальности! Ведь понятное дело, что БП европейских организаций сильно отличаются от российских... Да что говорить о странах, даже в пределах организаций да и то...
Вот интересный факт наблюдаю... Сегодня купил известную книжку от "Г. Буча и его друзей" Язык UML. Руковдство пользователя. Так там язык не позиционируется как средство для описания бизнес-процессов (только для ПО), даже все бизнес-расширения опущены.
-
Ага, мне кажется, тут есть два разных подхода к осмылсению этого вопроса:
1. Бизнес-процесс - как объект исследования управления
2. Бизнес-процесс - как объект подлежащий автоматизации
Мне думается - одно дополняет другое, но не обязательно затрагивает. Т.е. если стоит проблема автоматизации некоего БП, то это не значит, что я должен провести скурпулезный анализ этого БП во всех его проявлениях и рисках. Если такая нужда имеется - то ею занимается специалист-предметник. А если нет, то я просто строю системную модель БП как ИТ-специалист, прототипирую его, а дальше в итерационной процедуре приближаюсь к истине.
Но это же много проще.
Как найти корень уравнения: используем метод Ньютона(касательных). Большое значение имеет выбор начального приближения - это делает бизнес-аналитик, а я как ИТ-специалист, предлагаю процедуру последовательного приближения к истинному значению. Однако заметь никогда его не достигаю, достигаю лишь с определенной точностью.
Потому и в данном случае, что принять за начало, а что за конец процесса? На какой стадии, в каком месте, с какой точки зрения? Все это будет определятся целью и задачей.
Ну хорошо моделируем мы деятельность кладовщика - ну кто мешает сделать timetable его работы по приемке этого товара, посмотреть все операции? Никто, а что будет подлежать автоматизации? Если весь цикл разгрузки-погрузки, например с ипользованием робототизированной системы - это одно, а если учетных функций - т.е. документирование фактов хозяйственной операции - помоему другое совсем.
Нужно имхо избегать "паралича анализа". Делать нужно больше, чаще и быстрее: опыт накапливается - все будет хорошо. В конце концов не так уж много всяких вариантов, все определяется здравым смыслом порой
-
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?
IMHO для описания бизнес-процессов лучше не использовать никаких UML-диаграмм. Если всё же очень хочется - activity и sequence/collaboration. Любимой class diagram там делать нечего: сложна не столько структура, сколько процесс. Диаграмма вариантов использования не показывает условий ветвления, синхронизаций, передаваемых объектов, используемых ресурсов, временных факторов, событийной основы...
Есть ARIS вообще и eEPC в частности. IMHO лучше применять его (можно применять методологию и нотацию, а в качестве инструмента - хоть Visio).
А диаграмма вариантов использования нужна, чтобы показать варианты использования системы в рамках бизнес-процесса. Она - производная от модели бизнес-процесса.
-
А диаграмма вариантов использования нужна, чтобы показать варианты использования системы в рамках бизнес-процесса. Она - производная от модели бизнес-процесса.
интересная мысль. А может у тебя есть некий примерчик для визуализации сказанного?
-
Очень грубый пример БП:
1) Событие: пришёл заказ от клиента
2) Оператор бэк-офиса: проверить платёжеспособность и отправляет заказ поставщику; вход - невалидированный заказ, выход - валидированный заказ
3) Поставщик: выполнить заказ и доставить на склад; вход - валидированный заказ, выход - заказанный продукт, ресурс - склад
4) Оператор склада: учесть доставку заказанного продукта, передать складскую накладную оператору бэк-офиса; вход - заказанный продкут, выход - складская накладная
5) Оператор бэк-офиса: выписать счёт и счёт-фактуру, заказать доставку доставщику; вход - складская накладная, выход - счёт, счёт-фактура, заказ доставки
6) Доставщик доставляет заказ, клиент подтверждает доставку. Вход - заказанный продукт, заказ доставки, счёт, счёт-фактура. Выход - подписанный счёт-фактура. Ресурс - склад.
7) Клиент оплачивает счёт. Вход - счёт, выход - оплаченный счёт, платёж.
ERP-систему не внедряем, делаем АСУ склада. К большей части шагов бизнес-процесса наша система не будет иметь никакого отношения, что-то неявное и не слишком важное с точки зрения бизнес-процессов - уточним. И вообще, "контроль" нам неважен, а важен "информационный поток".
Поэтому из соответствующих шагов произойдут следующие варианты использования:
(2)=> Оператор бэк-офиса планирует доставку на склад
(3)=> Оператор склада учитывает доставку заказанного продукта; Оператор склада создаёт складскую накладную
(5)=> Оператор бэк-офиса планирует вывоз заказанного продукта со склада
(6)=> Оператор склада учитывает вывоз заказанного продукта со склада
-
Интересный пример, но действительно грубый, хотя довольно ясный и очевидный.
Правда не понятно почему ВИ - планирует доставку на склад? Планирование имхо не есть реализация или я чего-то не догоняю? Вообще почему у оператоов в данном контексте цель - спланировать доставку или отгрузку. Может уж тогда инициировать доставку/отгрузку.
Другой момент, ты пишешь что ВИ не дают ветвления и прочее. Но они не ддля этого и созданы, они создают варианты использования, варианты событий, контекст системы или подсистемы. Деталировка происходит на диаграммах последовательности, где упор идет на объъекты и диаграммах дейтельности, где упор идет на операциях, действиях.
Согласен, что гораздо проще показать процесс словами или нотациями типа SADT, ARIS, но ведь и диаграмма деятельности - практический аналог IDEF3
-
2 Galogen,
Все же удобнее описвать ВИ именно в виде текста, а ДД или ДП может дать только немного общего представления, все детали в тесте.
2 AlexTheRaven
А бы выделил два ВИ - Заказать товар на Склад и Предоставить Заказ на полки в Магазин
-
Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.
А что тогда лучше?
-
Цитата: Юрий Булуй от Декабря 24, 2006, 02:39:21 pm
Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.
А что тогда лучше?
Я согласен с Юрием. Все-таки UML можно только с некоторой натяжкой позиционировать как полнообъемное средство для описания бизнес-процессов. ARIS для подобных целей лучше подходит
-
Кто-то может внятно рассказать формальное описание бизнес-процесса?
Читая ветку, а так до конца и не понял чем бизнес-процесс отличается от какого-то другого процесса реальной жизни кроме того, что бизнем-процесс должен приносить прибыль или помогать ее приносить.
Т.е. хотелось бы услышать четкое, позиционированное определение БП, со всеми его входами и выходами, управлениями и ресурсами. + как это согласуется с АРИС.
Далее интересно было бы посмотреть на информационные признаки понятия БП и ВИ, а также на схожие признаки.
UML - это рассширяемая система обозначений - кто мешает расширить ее для описание БП? Таже EA вроде так и сделал?
Да и вообще имеет ли смылс говорить о БП как таковых без привязки их к ИС, ПО и т.п.
Мне интересно у нас клуб аналитиков в чем? В Бизнес-процессах? Системных процессах? Каких? развитие экономики в России? Как улучший БП обогащения одних и обнищяние других?
Почему ПО обязательно отталкивается от БП? Мы что пытаемся строить и делать? Если вообще пытаемся:-) Устроить свой собственный бизнес?
Помогать народу постигать азы бизнес-экспансии?
Я согласен построение ИС нужно для обеспечения и поддержки улучшение и т.п. главной миссии предприятия в целом и отдельных ее подсистем и БП в частности. Но соит ли так глубоко все связывать и привязывать к БП и только к БП? Если да, то интересно узнать а почему? Или а когда это является сверх важно, и когда можно этим пренебречь?
-
Далее интересно было бы посмотреть на информационные признаки понятия БП и ВИ, а также на схожие признаки.
Да мне бы тоже хотелось понять в чем приемущество описания, н-р, БП в АРИС по сравнению с БВИ в ЮМЛ?
Я согласен построение ИС нужно для обеспечения и поддержки улучшение и т.п. главной миссии предприятия в целом и отдельных ее подсистем и БП в частности. Но соит ли так глубоко все связывать и привязывать к БП и только к БП? Если да, то интересно узнать а почему? Или а когда это является сверх важно, и когда можно этим пренебречь?
В принципе я создавал такую ветку для БМ на скл.ру, думаю схоже http://www.sql.ru/forum/actualthread.aspx?tid=370422
[/quote]
-
Да в некоторм смысле - очень похожий вопрос и актуальные ответы.
Но мне хотлеось бы понять бизнес моделирование с одной стороны и модель бизнесу с другой - ведь это не одно и тоже?
БМ в РУП или просто интуитивно - это набор ВИ описывающих модель окружения, с позиций реально действующей бизнес-машины. При этом БВИ - аналог БП, но как утверждают некоторые ораторы этого форума - это совершенно не так.
Потому и задал вопрос.
1. Задайте описание БП формально. Типа БП это некая направленная деятельность, инициируемая событием или набором событий, использующая ресурсы различного типа(информационные, энергетические, физические, химические, людские и т.п.) для преобразования входов в ожидаемый выход=продукт. И может быть небоьшой примерчик такого процесса, с описанием и графической иллюстрацией, а также правиами вывода из этой информации уже основания для моделирования программных составляющих..
2. Увидеть разницы БП и БВИ+диаграмма деятельности
-
Рекомендую поискать в сети "ARIS vs IDEF", "UML vs IDEF", "ARIS vs UML".
Я например нашёл вот такой интересный документ - "Business Modelling: UML vs. IDEF" (http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf) (3Мб, 53 стр.). Поскольку ARIS является развитием SADT-идей, то часть наблюдений и выводов применима и к нему.
-
Я например нашёл вот такой интересный документ - "Business Modelling: UML vs. IDEF" (http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf) (3Мб, 53 стр.). Поскольку ARIS является развитием SADT-идей, то часть наблюдений и выводов применима и к нему.
Да документ дейстивтельно интересный. Спасибо за помощь
-
Вообще почему у оператоов в данном контексте цель - спланировать доставку или отгрузку. Может уж тогда инициировать доставку/отгрузку.
Ну рамки системы я такие выбрал для примера - планировать и учитывать. А инициирует взаимодействие что-то другое. Если не планировать использование ресурса - невозможно добиться его эффективного использования.
Другой момент, ты пишешь что ВИ не дают ветвления и прочее. Но они не ддля этого и созданы, они создают варианты использования, варианты событий, контекст системы или подсистемы.
А не важны ещё на этом уровне ни компьютерные системы и подсистемы. Построение АСУ - всего лишь один из способов оптимизации бизнес-процесса. Зачастую - далеко не самый эффективный.
Если в реальном бизнес-процессе есть ветвление, а показать его в ВИ нельзя, то нужно использовать что-то отличное от ВИ. Хотя, кстати, ветвление ВИ реализуется альтернативными последовательностями. 3-4 сложных ветвления (связанных не с обработкой ошибок, а с вариантами логики обработки) превращают ВИ в нечитаемого монстра.
Деталировка происходит на диаграммах последовательности, где упор идет на объъекты и диаграммах дейтельности, где упор идет на операциях, действиях.
В Activity нет важнейших понятий - владелец функции, исполнитель функции, ресурс. Нет разделения перехода на переход
-- контроля
-- физического объекта
-- информации.
Действительно, можно "расширить" Activity посредством введения новых стереотипов. Но не проще ли использовать готовый eEPC?
В Sequence нет ничего, кроме исполнителей функции и переходов непонятно чего.
Ни там, ни здесь нет событийной основы.
Согласен, что гораздо проще показать процесс словами или нотациями типа SADT, ARIS, но ведь и диаграмма деятельности - практический аналог IDEF3
А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?
-
А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?
Да нет, конечно, разве можно человека стеснять рамками. Просто один инструмент на все, от самого зарождения задачи и до ее полного ввода в практику использования. Согласись, что гораздо удобнее, чем разные кусочки делать в разных системах.
Вот сегодня bas жаловался, в одной и тойже конторе используют 5 разных case да еще и разных версий:-))
а eEPC - эриксон - пампкин (ли как его, ну что в ARIS или в EA)?
-
Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.
А что тогда лучше?
В таком контексте более важно иметь возможность оценки эффективности БП. Описать-то его можно хоть текстом. А вот произвести моделирование (симуляцию) с текстом невозможно, как впрочем и с UML диаграммами (да, я помню про существование ABC который одно время пытались прицепить к UML). Тут нужно либо тот же ARIS либо интсрументарий поддерживающий тот же BPMN. Я помню у IBM есть тула (склероз, а гуглить лень ...), которая поддерживает симуляцию по диаграммам a-la BPMN с переводом в BEPL.
Но если мы описываем БП просто чтобы понять "как устроено", чтобы выйти на требования к ПО, то вполне можно и на UML. Activity диаграммы рулят наряду с collaboration.
Кстати, мелькало на Rational Edge что-то про использования UML для бизнес-моделирования. На самом деле если у кого есть возможность потратить на это время -- можно там поискать.
-
Если в реальном бизнес-процессе есть ветвление, а показать его в ВИ нельзя, то нужно использовать что-то отличное от ВИ. Хотя, кстати, ветвление ВИ реализуется альтернативными последовательностями. 3-4 сложных ветвления (связанных не с обработкой ошибок, а с вариантами логики обработки) превращают ВИ в нечитаемого монстра.
Какова цель бизнес-моделирования, в частности в примере? Реинжениринг и оптимизация процессов, тем более без создания ПО? Эту задачу успешно решают именно инженеты от ИТ или все-таки это не совсем их домен?
В Activity нет важнейших понятий - владелец функции, исполнитель функции, ресурс. Нет разделения перехода на переход
-- контроля
-- физического объекта
-- информации.
Действительно, можно "расширить" Activity посредством введения новых стереотипов. Но не проще ли использовать готовый eEPC?
В Sequence нет ничего, кроме исполнителей функции и переходов непонятно чего.
Ни там, ни здесь нет событийной основы.
Скажем так, что уже до нас эти стереотипы разработали, при желании можно и воспользоваться, другой вопрос ЗАЧЕМ нужно описывать БП. А вот насчет отсутствия событийности ... так есть же понятие Business Event, которое есть в RUP, если мне не изменяет склероз. Да, стереотип, и что это плохо?
А есть ли вообще цель - использовать UML для всего (не академическая, а практическая)?
Вот к целям-то опять и вернулись :-)
-
Юра, насчет моделирования БП - ты, конечно, прав. Я тоже не слышал об интсрументах, которые используя модели поведения UML, могли бы трансформировать их в имитационные модели.
Для SADT есть. Есть трансформация IDEF3 в систему Арена или BPSimulator в CPN.
В ЕСОiii кажется есть реализация моделей сотояний в код.
Правда можно диаграммы состояний трансформировать в модели Stateflow Simulink Matlab, правда прямой конверации к сожалению из других средств я не встречал, но восможно разработать ToolBox например их XMI
-
Какова цель бизнес-моделирования, в частности в примере? Реинжениринг и оптимизация процессов, тем более без создания ПО? Эту задачу успешно решают именно инженеты от ИТ или все-таки это не совсем их домен?
Цель бизнес-моделирования в примере - выявление предметной области АСУ склада и написание корректных ВИ для этой АСУ. Эту задачу решают инженеры ИТ. В результате происходит оптимизация бизнес-процесса благодаря ускорению информационных потоков посредством АСУ.
IMHO реинжиниринг бизнес-процесса - это один частный случай оптимизации, а построение АСУ - другой частный случай (оптимизируется использование временнОго ресурса).
А вот насчет отсутствия событийности ... так есть же понятие Business Event, которое есть в RUP, если мне не изменяет склероз. Да, стереотип, и что это плохо?
Такое понятие действительно есть. В UML 1.0-1.1 (RR 2003), в Activity нельзя передавать (неизвестно что) объектам. В UML 2.0 (EA 6.5) действительно можно, причём определять, что передаёшь - контроль или информационный поток. Activity в UML 2.0 действительно можно превратить в ARIS eEPC. Жаль только, что это автоматически не даёт тулзе поддерживающей UML 2.0, возможностей модулей ARIS ABC, BSC и Simulation :).
-
Цель бизнес-моделирования в примере - выявление предметной области АСУ склада и написание корректных ВИ для этой АСУ. Эту задачу решают инженеры ИТ. В результате происходит оптимизация бизнес-процесса благодаря ускорению информационных потоков посредством АСУ.
А вот позвольте с вами не согласиться. Что такое ускорение информационных потоков. А главное зачем их ускорять? Думаю оптимизация потоков возможна. уменьшается общее количество ввода и повторения некоторых данных, данные становятся доступными сразу в необходимый момент. Облегчается анализ информации, получение важных и сложных выборок, своевременность и достоверность информации, возможность быстрой трансформации предстваления информации из одного вида в другой для большей наглядности, повышается степень защищенности, копируемости, сохранимости и прочая и прочая.
Т.е. причем тут ускорение - не очень понятно. Думаю ускорение тут не важно, важнее соразмерность, синхронность и своевременность т.е. 3С :-)
Сам изобрел...
Кроме того стоит более осмотрительно использовать понятия. АСУ - что есть - автоматизированная систему управления. Склад - это не основной процесс - это некоторая его часть - это накопитель ценностей, которые перетекают от производителя к покупателю. На чем мы делаем деньги? Именно на процессе накопления и перераспределения? Или все-таки на чем-то другом? Что такое торговая деятельность? Накопить мощности и распределить? А как же just in time режим. Вообщем я бы сказал все-таки не об АСУ, а об системе управления запасами. Warehouse Inventory что-то типа такого.
-
<...>Что такое ускорение информационных потоков. А главное зачем их ускорять?<...>
IMHO бизнес-процесс (основной, а не обеспечивающий) по сути - прохождение ценностей по преобразующим их функциям, создающим добавочную стоимость.
Добиться большей добавочной стоимости можно
- увеличив добавочную стоимость, генерируемую функцией при прохождении скозь неё единицы ценностей (увеличив "амплитуду" добавления стоимости)
- уменьшив время, необходимое для прохождения единицы ценностей сквозь функцию (т.е. скорость, или "частоту" добавления стоимости).
Увеличивать "амплитуду" могут системы анализа бизнес-процессов и САПР.
АСУ могут увеличивать только "частоту", следующим образом. Между функциями всегда есть переходы. Переход от одной функции к другой требует времени. Это время на информирование владельца и исполнителя следующей функции о том, что предыдущая функция над единицей ценности завершена, и можно начинать следующую. Именно эти передачи информации (информационный поток) в моём понимании и ускоряет АСУ. Разумеется, при этом должны соблюдаться соразмерность, синхронность и своевременность :) .
IMHO всевозможный учёт и анализ - не главные функции АСУ. Они нужны, чтобы выявить сбои в ходе бизнес-процесса и оценить его эффективность.
-
интерсное суждение, такое мне в голову не приходило. Мда не экономист я.
Возьмись за направление бизнес-анализа?
-
ОК, возьмусь :) . А суждения приходят в голову любому после прочтения Максовского "Капитала". Маркс IMHO был гений: он сделал бизнес-модель для общего случая, так сказать, class diagram, а не object diagram :).
Ну и ещё Макконнелл-Брю с Фишером есть.
-
ОК, возьмусь :) . А суждения приходят в голову любому после прочтения Максовского "Капитала". Маркс IMHO был гений: он сделал бизнес-модель для общего случая, так сказать, class diagram, а не object diagram :).
Ну и ещё Макконнелл-Брю с Фишером есть.
Саша, не пугай меня на ночь глядя, спать не буду. Хотя жена может будет довольна:-)
А вообще все зависит от области действия - ну вот не нужна мне бизнес-теория, хотя чувствую без нее тоже трудно.
-
ОК, возьмусь :) .
Не брешешь? Тогда стукнись в аську, я сменю тебе права на сайте - будешь статейки тискать и кое что в этом направлении публиковать. Предлагай как раздел назовем? Теория и практика бизнес-анализа? Или Бизнес для IT-специалистов? Ну что тебе на ум прийдет. Я создам раздел и вперед:-))
-
Ещё на тему соспоставления ARIS и IDEF от Репина:
2.9.1. Нотации IDEF0 и ARIS VAD 103
2.9.2. Нотации IDEF3 и ARIS еЕРС 107
2.9.3. Сравнение инструментальных средств моделирования ARIS Toolset и BPWin
http://www.bizbook.ru/listing.php?book_id=18203&page_num=103&reset
-
Не брешешь? Тогда стукнись в аську, я сменю тебе права на сайте - будешь статейки тискать и кое что в этом направлении публиковать. Предлагай как раздел назовем? Теория и практика бизнес-анализа? Или Бизнес для IT-специалистов? Ну что тебе на ум прийдет. Я создам раздел и вперед:-))
Я думал, что "возмись"="пеши исчо" :) . На самом деле - наверное, брешу. Опыт бизнес-анализа у меня есть, но он стремительно устаревает. Я сейчас скорее ситемный аналитик, а бизнес-аналитик и архитектор - не от хорошей жизни, а от остутствия результатов от "выделеннных" бизнес-аналитиков и архитекторов. Лучше бы этим разделом "выделенному" бизнес-аналитику заниматься. Тем более что со временим у меня - то достаточно густо (вот сейчас, например, понапридумывал и согласовал, и пока прототип не сделают, полегче), то совсем пусто (когда надо тестировать на достижение цели (!=тестировать на качество), придумывать и особенно согласовывать).
-
Я думал, что "возмись"="пеши исчо" :) . На самом деле - наверное, брешу. Опыт бизнес-анализа у меня есть, но он стремительно устаревает. Я сейчас скорее ситемный аналитик, а бизнес-аналитик и архитектор - не от хорошей жизни, а от остутствия результатов от "выделеннных" бизнес-аналитиков и архитекторов. Лучше бы этим разделом "выделенному" бизнес-аналитику заниматься. Тем более что со временим у меня - то достаточно густо (вот сейчас, например, понапридумывал и согласовал, и пока прототип не сделают, полегче), то совсем пусто (когда надо тестировать на достижение цели (!=тестировать на качество), придумывать и особенно согласовывать).
ну ты совсем то не отказывайся, может и не один будешь вести этот раздел, а вместе с другими. Просто опытом следует делится и его систематизировать, на форумах имхо трудно все это читать, тут много воды разговоров того сего