61

Бизнес-анализ и Целеполагание / Re: Формулировка цели

« : 30 Декабря 2011, 00:12:59 »

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

Ну если так категорично, то я категорически не согласен :о)) ИТ системы - они разные бывают. Одно дело система для фиксации каких-либо фактов (тех же формуляров выдачи/приемки книг), другое - что-то более интеллектуальное (продолжая аналогию - система планирования для пополнения библиотеки книгами)

Весь выигрыш бизнес получает от правильно поставленных процессов и наличия достаточной для принятия решений информации.

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

Вот, для обеспечения такой информации и нужна ИТ-система. В нужное время в нужном месте, что называется, и не более того.

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

62

Бизнес-анализ и Целеполагание / Re: Формулировка цели

« : 29 Декабря 2011, 16:13:35 »

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

вообще-то начать нужно таки с формулировки цели. С точки зрения ИТ поддержки бизнес процесса мировая наука ITSM шагнула достаточно далеко, чтобы более менее внятно это сделать - определить цель ИТ поддержки.

А я почему-то считаю что наоборот. На начальных уровнях не считают.

и да, и нет. если не считают, то не знают что НУЖНО считать, не знают ЧТО нужно считать, как считать и, главное, для чего. а если считают, то считают не то, т.к. опять же не знают для чего и как. оба варианта бесполезны в терминах цели, т.к. незрелое управление не может четко сформулировать цель.
Поэтому с этого надо начать.

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

а в военное время косинус может достигать четырех! (с)

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

А вот дискуссия может быть следующего характера: Какого уровня должен быть аналитик или руководитель (или что у него должен знать или у него должно быть для этого) , чтобы он мог описать цель IT проекта для Заказчика и главное измеримо.

я бы перефразировал: что должен знать subj о рисках и способах работы с ними, чтобы на заданном уровне качества управлять сервисом.

63

Бизнес-анализ и Целеполагание / Re: Формулировка цели

« : 28 Декабря 2011, 21:14:48 »

А как Вы будете измерять  указанную цель для ИТ? Как померять поддержан БП или нет? Обеспечена корректная и своевременная аналитика?

это очень интересная (в т.ч. для меня тема) и даже в чем-то занимательная. Во-первых, измерять можно что-то измеримое. Поэтому раз поддержка - неизмерима, то либо нужно ее привести к измеримому виду, либо не заниматься ерундой измеряя неизмеримое. (Альтернативный пример, сколько например километров между Ио и Фобосом? Хотя в принципе - это вполне себе тривиальная и давно решенная задача)

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

Коротко говоря, это не совсем правильная трактовка. Если не сказать: совсем неправильная. Бессмысленно измерять количество действий и прочих "физических" параметров системы, которая "поддерживает" бизнес процесс. Потому что это ничего не дает бизнес процессу.
Подобная трактовка характерна для начальных уровней зрелости управления ИТ.

Можно считать, что это предложение подискутировать... :о))

64

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 28 Декабря 2011, 20:53:59 »

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

дело в том, что это РАЗНЫЕ сущности, а Вы, видимо, подходите к ним как к одной.
поясню. насколько я понял, формуляр книги (эдакий вкладыш) содержит данные о предыдущих выдачах/сдачах книги, т.е. по сути является базой данных о перемещениях книги между читателями и библиотекой. записями (сущностями) этой базы данных являются отдельные операции выдачи/сдачи со своими данными о читателе и дате.
так что ложки нет...

P.S. 2 Galogen я что-то не уловил ранее. разговор идет только о сдаче книги читателем? т.е. это букинистический магазин, а не библиотека, получается? :о))
вообще говоря, система будет замкнутой, если добавить в нее выдачу книг читателям. тогда и поиск книг по каталогу добавится и т.п. операции, о которых я писал раньше

65

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 28 Декабря 2011, 20:37:55 »

Пардон за задержку.

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

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

Как ты определяешь (какие критерии) что две функции одинаковы/различны по нагрузке?

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

Да согласен может и так. Что исключить книгу из рассмотрения?

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

с таким же успехом можно и водку арендовать - в Ебурге / Челябе на этом целый бизнес построен и в некотором смысле даже формуляры есть, не говоря уже о CRM  :о))

не могу сказать, что понял посыл данной фразы. повтори плиз?

Без проблем

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

:о))

смысл в том, что суть анализа и построенной на его основе модели - определить информационные связи функций, а не их последовательность во временном аспекте

66

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 22:27:59 »

других видимо нет

другие не занимаются такой ерундой - они моделируют сразу на UML

67

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 22:26:59 »

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

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

рисуем А0, ориентируемся на цель, рамки, сущности. потом пробуем детализировать, пытаясь увязать модели по глубине, чтобы на одном уровне определялись функции примерно похожие по нагрузке, например: принять книгу, заполнить формуляр - д.б. на модели одного уровня.

тут будут уместны твои вопросы

1. Может ли, к примеру, входящий в блок Принять книгу поток Книга оседать в этом блоке и не иметь выхода, кроме пометки о сдаче в формуляре?
2. Если выходящим должен быть "принятая (сданная) книга", то должна ли она выходить из системы, если мы рассматриваем границы абонемента библиотеки?
3. Если мы рассматриваем модель с точки зрения библиотекаря абонемента, может ли быть механизмом сам библиотекарь-абонемента?

попробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.
Тут либо книга и формуляр всегда вместе "путешествуют", либо по-разному...
2. Почему выходом должна быть книга-то? Или мы рассматриваем в качестве системы операцию сдачи/приемки? Если нет, то вообще говоря, выходов может быть много и разных, отчетность какая-нибудь с анализом востребованности литературы, например... Короче говоря, надо на задачу смотреть (цель какая? границы какие? - не могу сказать, что сейчас внятно понимаю термин "границы абонемента библиотеки" )
3. ну а почему нет. если хочешь, назови его "я - библиотекарь абонемента".

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

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

твой пример с книгой, очевидно, вызывает трудности из-за того, что границы системы не ясны и с точкой зрения не все в порядке, или мне только так кажется.

68

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 20:30:19 »

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

в теории - да.
вопрос-то в том, как правильно выбрать точку зрения, определить границы системы, увязать входы/выходы/управление, то, сё...
короче, описать модель как систему...

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

ну да, возмещение ущерба - процесс, запускаемый претензией. все остальное в обсуждаемом контексте несущественно...

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

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

69

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 17:49:49 »

1. Буду продолжать придерживаться своего мнения - это не алгоритм, в нем, например, не говорится что может быть выходом, а что не может. А термин "стараясь понять" откровенно порадовал. Чтобы "понять" смысл предложения, нужно не только буквы знать, и в слова их уметь складывать, но и что-то еще - правда? Вот этого-то и нет у студентов.

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

3. Следуя логике "клиента и белья", на модели непонятно откуда взялся товар (который оказался проданным) :о)))
Здесь может быть применена известная формула тов.К.Г.Маркса "товар-деньги-товар", например, на момент получения денег на вход товар вполне может быть на складе продавца (но может и не быть - вспоминаем схему работы наших интернет-магазинов :о))))
Хотя я бы деньги на входе заменил на какую-нибудь заявку, а проданный товар на выходе - на чек на проданный товар. Но это существенно зависит от точки зрения. Да и границы системы было бы неплохо определить...

70

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 24 Декабря 2011, 20:37:00 »

Ну привет, приехали...
Проблема в том, что "писатели" моделей многого не знают, и не понимают многого. Возможно, их просто плохо учили :о)) Nothing personal only business))) А может им просто до фонаря.
Очевидно, что они (подобные студенты) не знают / не понимают:
 - что такое "функция"
 - какие виды информации (данных) используются, как они используются / преобразуются в информационные объекты
 - что такое состояние, в т.ч. состояние информационных объектов
 - какие операции могут выполняться с информационными объектами (их можно назвать в ОО стиле - методами обработки), как меняющие состояния объектов, так и порождающие из одних объектов другие.
(кстати, эти преобразования - одна из самых сложных тем, потому что здесь очень большая вариативность возможна)
ну и так далее (навскидку вспомнил далеко не все)

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

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

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

71

Обучение / Re: Дисциплина "Системная инженерия"

« : 21 Декабря 2011, 00:48:48 »

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

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

72

Методологии / Re: Методология PDM-систем

« : 19 Декабря 2011, 17:04:16 »

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

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

73

Методологии / Re: Методология PDM-систем; управление проектами на промышленном предприятии

« : 19 Декабря 2011, 15:17:29 »

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

74

Методологии / Re: Методология PDM-систем; управление проектами на промышленном предприятии

« : 19 Декабря 2011, 13:54:31 »

С этого можно начать, в качестве пилотного проекта (для предприятий, занимающихся проектированием).

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

75

Обучение / Re: Дисциплина "Системная инженерия"

« : 18 Декабря 2011, 14:37:51 »

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

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