Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Ich

Страницы: 1
1
А мне понравилось. Добротная студенческая работа. Автор излагает свое текущее восприятие окружающей реальности, открывает мир и раздвигает границы своего познания. Да, наивные диаграммы и некоторые высказывания. Но для студенческого сборника очень неплохо. На прошлой неделе довелось слушать два подобных доклада на SECR-2010. Вот это было ужасно.

У Вас хороший стиль изложения. Добавить к этому опыта и знаний, и все будет отлично. Впереди еще много интересных открытий :)
Удачи Вам, Павел!

2
Доверие это вообще тонкий момент, ему в 14 пунктах не научишь.

Обычно такие пункты "пишутся кровью" опыта успешных и неуспешных проектов.  Их можно назвать декларацией клиентоориентированности, которую Мария Евграшина попыталась сформулировать для своей команды. Конечно, все сложнее и об "эффекте карго" нельзя забывать - что работает в одних проектах, может в других и не работать. Но должны быть общие принципы работы с клиентами, принимаемые в команде. И здорово, когда они сформулированы и озвучены.

Конечно, проще сказать "самое главное это искренность...". Незабвенный Жеглов в ответ на подобный вопрос такой отмазкой не ограничился, а выдал Шарапову 6 правил Глеба Жеглова. А как иначе опыт молодым передавать? :)

Не нравится "манипуляция", назовите "управлением отношениями с клиентами" :)

Разница есть. Ее еще Жеглов в своих правилах сформулировал :)

С первого мига проявляй к человеку искренний интерес - понимаешь, не показывай ему интерес, а старайся изо всех сил проникнуть в него, понять его, узнать, чем живет, что собой представляет; и тут, конечно, надо напрячься до предела. Но, коли сможешь, он тебе все расскажет...

И сравните:

самое главное это искренность, если вы сможете ее изобразить - считайте, что дело в шляпе. Работает на всех уровнях... :)

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

Я думала, тут взрослые мальчики сидят, кого стесняться?... :)

Новая аватарка специально для взрослых мальчиков?  ;)

3
Вот это то и самое интересное .... то что вы описали действие в СИСТЕМЕ ... это функция поиска в системе. Является ли "поиск по базе данных" бизнес-процессом?

Кто ж спорит-то. Поиск - это сервис, ну или функция в системе. Входит в описание некоего бизнес-процесса "Обслуживание клиента", например, который собственно и моделируется. Кроме этой функции в процессе участвуют и другие. И вопрос в том, как их правильно связать. Честно говоря, мне сложно понять, как обсуждение темы бизнес-процессы vs функции приближает нас к сути поставленного вопроса. Вы хотите сказать, что функции системы не могут входить в описание бизнес-процесса? Или что они не могут связываться логикой событий и ветвлений?

4
Интересно, обрастет ли когда-нибудь спецификация BPMN методологией, приемами и прочими бэст практис? UML тоже когда-то существовал практически только в виде многостраничной спецификации, давая возможность каждому моделировать в меру своего понимания. Зато сегодня все знают, когда лучше использовать "include", а когда "extend" в use case diagram и что такое "уровень моря" по Коберну.

<<Если слово "мама" перевести на несколько языков, изменится ли его смысл?

Но если в одном языке собираются несколько вариантов слов "мама", значит это зачем-то нужно? Значит есть определенные нюансы звучания в определенных ситуациях. Так и здесь, ну, например, можно предположить, что события можно использовать в моделях только внешние и временнЫе, а "найден/не найден" - это внутреннее событие, поэтому в этом случае лучше использовать другие средства.

<<Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...

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

5
Как сказано в спецификации, BPMN объединил все лучшее из различных методологий моделирования. И в том числе некоторые моменты, описывающие в этих нотациях одно и то же, но разными средствами.

Например, моделируем простой бизнес-процесс, где есть действие "Поиск документа", который может быть найден или не найден, и в зависимости от этого разворачивается дальнейшее действие. В EPC это бы однозначно моделировалось двумя переключающими событиями "Документ найден" и "Документ не найден" (соответственно в BPMN это будут Intermediary events). В IDEF3  - XOR перекрестком (BPMN - Exclusive databased gateway), в  UML Activity Diagram - ветвлением decision и условными переходами (здесь опять же Exclusive databased или Exclusive event-based gateway ). А еще можно просто сделать условные переходы (conditional sequence  flow).

Так какой же вариант моделирования будет правильным?

Страницы: 1