376

Примеры / Re: Деловое моделирование с использованием UML. Производство. Примеры.

« : 17 Ноября 2008, 15:15:26 »

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

377

Конференции Семинары и Тренинги / Re: Направление серии семинаров

« : 17 Ноября 2008, 13:21:32 »

Вот из-за НДС, часто большим конторам невыгодно связываться с ПБОЮЛ .. эта форма удобна при работе с физлицами в качестве клиентов.

378

Конференции Семинары и Тренинги / Re: Направление серии семинаров

« : 13 Ноября 2008, 13:45:18 »

дешевле зарегистрировать ПБОЮЛ ... тогда только 13% в виде налогов нужно будет отдать :-).

379

IDEF ARIS BPMN и пр. / С чего начать при построении модели на BPMN?

« : 12 Ноября 2008, 11:25:51 »

PS. Юрий, правильно говорить BEPL, а писать все же - BPEL.

Чистой воды опечатка ... сорри.

380

IDEF ARIS BPMN и пр. / С чего начать при построении модели на BPMN?

« : 11 Ноября 2008, 16:30:32 »

2WJ:
Возможно мы действительно о разном ... но ...
1. Не понимаю, почему as-is\to-be обязательно возникают при детализации процессов? Почему речь идет об уровнях ... что, шаги бывают исключительно вглубь? Речь шла буквально о том, что браться за BPMS и SOA не имеет смысла без понимания той же EA ... посему первыми шагами должно быть построение той самой EA (с необходимой и достаточной детализацийе, для решения поставленных задач конкретной организации) в части BA и прочих архитектур. Это и есть первые шаги ...
2. По поводу buzzwords ... скажите мне пожалуйста примеры организаций в России, где серьезно рабают на базе SOA и BPMS, чтобы можно было говорить что это действительно системный подход? Какой уровень зрелости бизнеса и ИТ должен быть в такой организации??? Пока что на том же Oracle Tech Days не было ни одного серьезного примера ... только куски, где использованы некоторые подходы SOA и прочия.
3. На тему противоречия.  Цитата:

BYUR: >> При этом абсолютно очевидно, что если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него. Если подходить имеено так, то не думаю что слудует "... приготовьтесь к тому, что в этот момент Вы просто начнете все с начала".

WJ >> Сами себе противоречите. Сначала говорите, что выбор BPMS - 5 шаг, а потом говорите, что надо изначально под него затачиваться. Или я Вас не правильно поняла? Что есть "выбор вендора"?

Я же вроде вполне ясно написал ... "если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него". Что означает буквально следующее ... имея EA можно принимать решение об использовании или неиспользовании BPM System. После чего и "затачивать" _конкретные_ процессы под нее.

381

Теория моделирования и нотации / Re: на какой диаграмме изобразить Металлообработку

« : 11 Ноября 2008, 11:07:53 »

Юра!
Ты испортил всю малину! Идея с классами сразу была понятна, но было так интересно, для чего человеку это надо, а теперь ты выдал волшебный ответ и нам не расскажут, для чего нужен UML в металлообработке

Извините, я не понял ... :-(

382

Конференции Семинары и Тренинги / Re: Направление серии семинаров

« : 10 Ноября 2008, 23:24:59 »

А что бы не сделать семинар на действительно волнующую многих тему, например, «Как писать ТЗ»? )

Тема действительно многих волнует ... будет аншлаг ... но стоит ли его делать for free?

383

Теория моделирования и нотации / Re: на какой диаграмме изобразить Металлообработку

« : 10 Ноября 2008, 18:02:15 »

Да вобщем-то можно даже и в ТАКОЙ поставке изобразить ... на той же диаграмме классов. Введите стереотип <<Процесс>> и покажите что ваши классы "Вальцовка" и т.п. с данным стереотипом наследуются от суперкласса "Металлообработка" .... :-).

384

IDEF ARIS BPMN и пр. / С чего начать при построении модели на BPMN?

« : 10 Ноября 2008, 17:53:48 »

Если Вас интересует реинжиниринг бизнес-процессов - то, возможно, это 5, 8... а скорее 10000... шаги (это уже не имеет значения, поскольку Вы вряд ли до них доберетесь ) Мой личный опыт (не утверждаю, что нет опровержений): я не видела НИ ОДНОГО примера, когда бы в организации существовал BPM, образовавшийся в результате реинжиниринга.

Так, давайте по-порядку ... а то я перестал понимать "шо вы имеете ввиду" :-) ...
1. С какой радости возник реинжениринг (в терминах Хаммера и Чампи) Для того чтобы понять источники ордеров в организации нужно делать реинжениринг???
2. Я утверждаю, что браться за BPMS и тем более SOA не имеет смысла, если вы не понимаете как устроена ваша оргазация, т.е. не имея модели ее Enterprise Architecture (другой вопрос, с какой степенью детализации она присутсвует и каков ее ЖЦ). Понимая EA, можно говорить и о BPMS ... и на основании EA принимать решение, будет ли использоваться BPMS, SOA и прочия buzzwords .... Именно отсюда и вытекает, что собственно BPMS и прочия есть 5 и 8 шаги. При этом абсолютно очевидно, что если вы принимаете решение об использовании BEPL движков, то нужно выбирать решение конкретного вендора и "затачиваться" под него. Если подходить имеено так, то не думаю что слудует "... приготовьтесь к тому, что в этот момент Вы просто начнете все с начала".
3. Из сего делаю вывод, что вы либо не поняли что имелось ввиду, и пошли по неверной цепочке рассуждений на тему реинжениринга, либо хотите таки сказать, что нужно "сажать, сажать, не дожидаясь весны" ...?

Смотря о чем Вы говорите. Если об инструментарии - то именно Suite, если о системе, построенной на основании использования этого инструментария (грубо говоря - то, чего получилось на конкретном предприятии) - это однозначно Systems.
) устареваете

Тут больше вопрос к вам -- что вы имели ввиду (прямо как в старом одесском анекдоте :-)) ... цитата "из вас":

"если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре)."

Suite, как вы верно заметели, действительно относиться к инструментарию ... и употребляется в настоящем времени (например с подачи того же Gartner) как обозначение класса систем. Тут возникает та же ситуация, что и с SQL Server -- это и класс продукта и ... да, одноименный продукт от MS. Аналогично и тут ... (Oracle) BPM Suite .. использован тот же маркетинговый прием ... Посему, дабы избежать путаницы (учитвая сложность интерпретации Suite вне контекста) имеет смысл говорить "System".
Теперь о смысле фразы ... получается, что вы предлагаете для процессоного управления сразу же использовать определенные тулы ... Это примерно то же, что сказать -- "если вы хотите чтобы у вас в компании с требованиями было все ОК -- используйте requirements definition and management tools". Хотя аудитории UML2.RU отлично известно, что для того чтобы эффективно использовать те самые RDM Tools нужно поставить процессы, классифицировать требования и только потом можно будет использовать tools ... иначе это будет неэффективно.  Другой вопрос -- что занимаясь постановкой процесса you should keep in mind tools will be used.

385

IDEF ARIS BPMN и пр. / С чего начать при построении модели на BPMN?

« : 07 Ноября 2008, 16:47:40 »

Топикстартеру:
если Вы всерьез заинтересованы в процессном управлении и в автоматизации процессного управления, то Вам следует познакомиться не только (и не столько!!!) с BPMN, а обратиться к теме BPMS (Business Process Management Suite) и SOA (сервисно-ориентированной архитектуре).

Думаю, что обращение к BPMS и тем более к SOA при заинтересованности в процесном управлении -- это 5 и 8 шаги соответственно. Для начала нужно построить классификацию БП организации, на основании некой референсной модели. Например для телекомов есть очень неплохая классификация eTOM. При "обработке напильником" можно применить для любой организации, оказывающей услуги.

Кстати в термине BPMS "S" отнюдь не Suite, а System ....

386

Проектирование / Re: Как описать существующий интерфейс системы?

« : 01 Ноября 2008, 12:05:24 »

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

387

Консалтинг и Внедрение / Re: Необходимость внедрения отраслевого решения. С чего начать?

« : 01 Ноября 2008, 11:56:02 »

Не советую заниматься внедрением учетной системы без четкого определения процессов контура фнансово-экономического управления (ФЭУ). Учитывая вашу ситуацию -- т.е отсутсвие должносных интсрукций и т.п. рекомендую сначала провести постановку ФЭУ, пригласив для этого соответствующих консультантов. После того когда будет определно как вы будете оценивать эффективность процессов (в т.ч. операционных) и вообще какая информация (метрики, KPI) нужна для принятия управленческих решений -- можно будет приступать к написанию Концепции. Иначе есть риск получить классический безнадежный проект.

388

Примеры / Re: Создание моделей вариантов использования

« : 31 Октября 2008, 17:37:12 »

Плохо, раз ничего не поняли :-( ...
По-всей видимости вы не поняли самого главного -- юзкейсы это не ФУНКЦИИ системы, и не всегда бизнес-процессы как таковые ... это цели пользователя, т.е. взгляд на систему со стороны пользователя, а не со стороны декомпозиции функций системы.
Разложение системы на меньшие составляющие в каком смысле? С т. з. функциональности системы? Или с т.з. ее архитектурного дизайна???

389

Системный Анализ и Требования / Re: Относится ли данное требование к "нефункциональным"?

« : 24 Октября 2008, 11:46:12 »

Администрирование и безопасность по своей сути пограничная вещь между технологиями и бизнес-процессами. С одной стороны разграничение\ограничение доступа к информации -- одно из ключевых требований бизнеса. Сильно сомневаюсь что бизнес-заказчик пожелает, чтобы к данным имел доступ кто угодно. С другой стороны -- решения по обеспечению безопасности стали достаточно стандартными, и рассматриваются часто как составня часть информационных технологий. В реальности все зависит от того, какую точку зрения принять в конкретном проекте. Лично я в данном случае сказал бы что это функциональное требование. Т.к. есть явный пользователь системы (например роль Администратор), пусть и "вспомогательный", но для которой система предоставляет какие-то свои возможности (вывод списка пользователей системы с доп. информацией).
По ГОСТ 34.602 это можно смело выносить в раздел требований к функциям (задачам), а в требованиях к безопасности перечислить требования более высокого уровня (например о том, что вообще должно быть разграничение доступа и т.п.)

390

Обучение / Re: Аналитическая задачка: Штучная касса в продуктовом магазине

« : 20 Октября 2008, 11:31:09 »

Говоря о бизнес-показателях - все достаточно просто -- нужно посмотреть какие KPI используются и как они сбаллансированы. Т.е. ритейлер -- это система, состояние которой во времени оценивается через набор метрик. Очевидно, что набор KPI вполне может быть разным для разных этапов стратегического развития ритейлера. Например, если они недавно открылись,  "проедают" инвестиции и их краткосрочная задача -- сделать магазин популярным в окрУе, то маржинальность будет не самым главным показателем (как и объем суточной выручки) и, скажем, значения KPI по скорости обслуживания (например есть показатель скорости прохождения через кассу 20 товаров, которым "меряются" кассиры) будут иметь более высокий вес.
Следовательно, эта касса будет "играть" на показатель суточной выручки и усредненное значение "пропускной способности". Соотнеся ожидаемые приросты этих показателей с затратами на эту точку -- можно оценить ее эффективность, но оценка не будет "чистой", т.к. на увеличение суточной выручки может влиять еще, скажем, наличие "популярного" товара или изменение ассортимента.
Явные метрики для данной кассы -- а именно объем продаж через нее и расчет ее эффективности по отношению к затратам на нее, так же как и "неявная польза" (например, обучение новичков работе кассира) не рассматриваем.