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

×


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

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


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
46
2 Trigger
еще раз повторю, что BPMN не совсем моя тема. Но очевидно, что процессы - не ваша.
Ваши варианты (циклический, множество) могут соответствовать алгоритму программы (это парадигма, в которой, видимо, вы думаете).
С процессами дело обстоит несколько иначе. Не нужно описывать никаких множеств экземпляров процессов и т.п. ерунды. Процесс он на то и процесс, чтобы для любого количества экземпляров, которое только может встретиться в жизни, нарисовать ОДНУ схему (описание) процесса. Всё! Все остальные экземпляры должны будут в точности его повторять - в этом суть процессного подхода! Всё всегда одинаково! Нет затрат на варианты, так как все варианты учтены в процессе.

Общетеоретически, правда, можно посчитать, что персонал или стойка регистрации (не процесс!) находится в двух состояниях: ожидание клиента или регистрация клиента на рейс. Но с точки зрения процесса это несущественно. Это из-за использования всё той же программистской парадигмы... о которой нужно поскорее забыть при работе с процессами...

Поэтому присоединюсь к коллеге АБ насчет события запуска. Но не уверен, как это можно показать в BPMN (в ARIS могу пояснить, но не думаю, что они далеко друг от друга отстоят). Ну и, разумеется, считать число появлений и экземпляров совершенно не нужно, разве что для планирования числа стоек и количества обслуживающего персонала, но тогда придется кое-что еще посчитать.


47
Не по теме.
Не знаю в деталях, что BPMN думает по этому поводу, НО!
приведенный пример не является "вечным процессом".
Во-первых, существует событие "начало регистрации на рейс"
во-вторых, существует событие "конец регистрации на рейс" (как вариант может быть рассмотрено событие "все пассажиры зарегистрированы на рейс")
т.е., формально говоря, процесс не вечный.
на языке алгоритмизации подобные процессы могут быть названы циклическими за счет многократного выполнения экземпляра подпроцесса "регистрация пассажира" между событиями начало/конец.

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

48
Цитата: div
Тем не менее, так и говорит, не так грубо, конечно. А что еще аналитик может сказать? Переработки не приветствуются, т.к. снижают качество и приводят к "выгоранию" людей.

Может тогда что-то в консерватории подправить? И пулемет на крышу...

Цитата: div
"Не с первого раза", но в "заданные сроки" может получиться только если в плане было запланировано "не с первого раза". У нас time driven development, график выхода продуктов расписан на год вперед, поэтому даже на 1 день позже заданного срока закончить работу нельзя. Если не успеваем, то объем работ режется по мере приближения срока, сокращается функционал.

Почитал я тут по совету здешних коллег Голдратта "Критическая цепь", а сам думаю, что я делаю не так? То что другие делают не так - это мне видно. Знаю, что и у меня своих огурцов тараканов изысков достаточно много.
Одного я понять не могу, почему подход "я свои 16,7 отработал" так живуч? Чем людям нравится работать не на результат, (которым не то чтобы гордиться хочется, пусть чтобы хотя бы не стыдно было), а за часы? Что они им дают? Что вообще эти люди дома детям о своей работе рассказывают? "За последний месяц я провел в никому не известном проекте - 89,3 часа?"

То что ПМы их к этому поощряют, ясно, и то что ПМу это выгодно, тоже ясно. Зарплата/премии - тоже ясно. Но неужели им не хочется хотя бы заработать в десять раз больше? Часов-то в месяце 31*24 = 744 всего, из них рабочих 168, ну 200, ну 250, 300 наконец... Всё! Больше физически нету. Зачем за часы-то работать? Не понимаю...

49
еще нужно русский язык заставлять учить, скоростной набор на клавиатуре (на разных раскладках) и искусству коммуникаций, включая презентации

50
Коллеги, я Вас понял. У нас та же картина.
В типовом случае имеется чехарда заданий, куча часов, по которым отчитались исполнители, каша результатов.... над каждым исполнителем (или над его начальником) стоит толпа ПМов, требующих, чтобы работа именно его проекта выполнялась в первую очередь, т.к. горят сроки. Немного утрирую, но тем не менее.

Да и реплика моя была не в том, как у Вас идет управление рабочим временем. Но как при всем притом контролируется результат? Что, по-моему, является прямой обязанностью либо ПМа, либо архитектора. Не поверю (даже не убеждайте), что, например, аналитик, приходит и грит: я свои 16,7 часов, которые ты мне дал, отработал согласно плана/задания/итп - вот тебе что успел/сумел сваять, отвяжись...
Также сложно поверить, что все всегда получается в заданных рамках в соответствии с требованиями ТЗ, пусть не с первого раза, но в заданные сроки.  

P.S. тема управления разделяемыми ресурсами не очень интересна, т.к. есть ощущение, что я в этом чуточку понимаю (хоть это и субъективное мнение)

51
Цитата: alex6565
Поэтому я воспользовался именно этим подходом 

Да я не в претензии... просто хотел наглядно показать связь зон ответственности этих ролей. А так... это вообще может быть один человек...

53
Позволю себе встрять и внести, так сказать, нотку протеста.

Цитата: alex6565
Мне кажется, что если отнести пункты, приведенные ниже, к более или менее формализованным этапам ЖЦ проекта, это поможет точнее ответить на заданный вопрос.

Честно говоря, в силу "лаконичности" фрагмента, пробежался по нему лишь поверхностно и, возможно, пропустил ту суть, о которой планирую сказать сейчас.

Дело в том, что независимо от того, какое деление на этапы ЖЦ ИТ проекта (а, кстати, что называем "ИТ проектом"? разработку софта или что-то иное, например, какой-нибудь инфраструктурный проект?) используется, они [этапы] имеют между собой "мостики", являющиеся продуктами этого этапа. Так вот участие указанных выше персон, выражающееся в некотором содержании их деятельности, в рамках каждого этапа сводится к некоторому участию (частично или полностью) в создании этого продукта или его компонентов.

Поэтому сначала нужно определить этапность с точки зрения таких продуктов [результатов этапа], по возможности выстроив их в дерево или, что проще, в цепочку - это уже довольно близко к ИСР (или WBS), т.е. сферы ответственности ПМ. Но тут в дело вступает зависимость между содержанием проекта и компетентностью ПМа в этом (либо просто масштаб проекта, например, функциональный). И сразу становится необходим архитектор... Впрочем у Брукса и об этом тоже написано... (я, кстати, по его совету прочитал "Человека продавшего Луну" - рекомендую, да и времени займет немного)

54
Цитата: div
Близко, но не совсем так. Время аналитика (40 часов в неделю) делиться между ПМами (например, 10 часов ПМу№1, 30 часов ПМу №2). После этого ПМ №1 говорит аналитику, что тому делать 10 часов, а ПМ №2 - что аналитику делать 30 часов. Если в конкретную неделю на проекте №2 есть работы только на 1 час, а на проекте №1 есть ждущие задачи, то можно с согласия ПМа №2 поработать на проект №1 39 часов.

Они у Вас кирпичи что ли кладут, аналитики-то? как в свое время говаривал старина Брукс: время выполнения работы одним исполнителем может на порядок (или даже больше) отличаться от времени работы другого исполнителя. Мог бы привести десяток-другой примеров, но думаю, что и у Вас их есть предостаточно.

Я признаться не верю, что ПМу важно количество часов, отработанных аналитиком, а не результат конкретной работы с учетом его места в конечном продукте проекта. Ну а если, не дай бог, дело так и обстоит, то гнать надо такого ПМа... или контору разгонять...

55
совершенно верно, даже видел где-то недавно отличную презентацию на эту тему....

56
что-то мы (Вы!) уже в какие-то дебри зашли

Цитата: gshamanov
По второму примеру - более конкретно: кладовщик, формирующий партию товара скоропортящегося, для отправки покупателю должен быстро получить от информационной системы расположение на складе самой "старой" партии товара. Таким образом увеличивается пропусная способность склада при той же площади. 

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

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

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

Цитата: gshamanov
Бизнес-процесс несомненно первичен, т.к. "автоматизация бардака приводит к автоматизированному бардаку". Система должна давать возможность принять решения вовремя по бизнес-процессу - в этом ее эффективность, часто без ИТ-системы решение принимается поздно. При этом если без внедрения системы принять решение невозможно, то эффективность считается.

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

57
2 SALar
PLS дайте ссылочку на Цель3

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

58
1. Это я к тому, что есть ряд систем (наверное, даже типов систем), для которых "померить эффективность можно и достаточно просто", а есть те - для которых это совсем непросто. И потом есть разница между "бизнесом" и "бизнес процессом". Наличие самого что ни на есть эффективного бизнес процесса совсем не означает наличия эффективного бизнеса.

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

3. Т.к. эффективность является соотношением прибыли и затрат, то если бизнес система не меняет существующего соотношения (в положительную, разумеется, сторону), то она  не может считаться эффективной с точки целей бизнеса, как бы ни кичились ИТишники ее совершенством.

P.S. А Голдрата (по крайней мере первую книжку) почитать все-таки порекомендую

59
Цитата: gshamanov
... Для такого класса ИТ-систем померить эффективность можно и достаточно просто. Можно даже в человеко-часах посчитать сэкономленных бизнесом или в деньгах прибыли от вовремя принятого решения.

поясните, плиз, для какого ТАКОГО класса ИТ систем "померить эффективность можно и достаточно просто". и еще поясните как? - это очень интересно
А вообще-то в человеко-часах экономия бизнеса не меряется. Т.е. посчитать-то конечно можно, можно даже заказчику втюхать, что у него всё-всё стало в разы и в десятки, сотни раз эффективнее, но скорее всего этого не произойдет.
Дабы не быть голословным, отошлю к старине Голдрату (более сведущему чем я): Вы стали меньше тратить, т.к. уволили какое-то количество человек? Вы стали больше зарабатывать?

60
Цитата: gshamanov
Т.е. на выходе и входе верхнего уровня такой модели необходимо вводить сущность "запись в формуляре". Не получится большое количество таких сущностей на входе-выходе?

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »