1

Системный Анализ и Требования / Re: Управление требованиями на долгоживущем проекте

« : 17 Февраля 2012, 13:41:35 »

Это скорее вопрос ведения компетенции по проекту. Если хочется оторвать компетенцию от команды и участников проекта, то можно вводить дополнительные инструменты. Только надо учитывать, что накладные в таком случае на работу появляются  и достаточно большие, поскольку необходимо отслеживать связные требования, устанавливать связи и все такое прочее.
Из собственного опыта: мы ситуацию с противоречивыми требованиями решали введением итераций разработки (версий). Версия должна быть обозрима, но при этом достаточно длительна для удобства разработчиков. Длительность версии определяется исходя из набора требований-изменений, которые могут быть оценены на непротиворечивость и реализуемость.
Процедура планирования включала два этапа:
1. Выбор из всего набора нереализованных требований самых важных и необходимых. При этом все требования фиксировались в беспрерывном режиме, а отсечение дубликатов и откровенно лишних происходило на этом этапе.
2. Оценка для реализации на совместимость и возможность принципиальной реализации. Здесь же появлялись и оценивались сроки.

2

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

« : 11 Января 2012, 18:07:22 »

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

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

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

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

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

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

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

Спасибо. Постараюсь прочесть.

3

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

« : 08 Января 2012, 19:18:26 »

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

1. Мне достаточно сложно вести дискуссии по вырванным из абзацев фразам. Такое ощущение, что собеседник даже не читает. Это в части ответа на "какого-такого".
2. По поводу как померить:
Никогда не внедряли систему с кассовым обслуживанием? Где существуют нормы на обслуживание покупателей в секундах?
Второй типичный пример: сбор информации для принятия решения занимает до создания системы 2-3 часа, система эту информацию предоставляет оперативно - разница есть? Или ее тоже померить нельзя? И таких примеров могу приводить десятками их своей практики.
3. В моей практике ни одна система по поддержке бизнес-процессов не способствовала сокращению штатов. Люди просто нагружались другими делами.

4

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

« : 02 Января 2012, 20:36:59 »

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

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

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

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

5

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

« : 29 Декабря 2011, 23:44:11 »

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

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

6

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

« : 29 Декабря 2011, 23:41:40 »

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

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

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

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

7

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

« : 27 Декабря 2011, 23:30:04 »

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

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

8

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

« : 27 Декабря 2011, 17:12:57 »

Понимаете, мне кажется Вы уводите обсуждение в другую, не нужную мне плоскость. Обсуждая вопросы IDEF0 моделирования, я точно очерчиваю вопросы дискуссии. Как обеспечить проверку правильности соблюдения баланса потоков сущностей (данных, информации), как проверять, что они корректны?

В данной дискуссии, я пытался ответить участникам (и себе )) ) на вопрос: как сам определяю моделируемые сущности, т.е. выделяю необходимые для модели.

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

Эдуард, попробуйте попользовать некоторое время нотацию Щедровицкого. Она малоизвестна, но мне кажется она хорошо прочищает мозг. После нее станет проще верифицировать нотацию IDEF0.

Присоединяюсь к вопросу о ссылках - изучить очень интересно.

9

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

« : 27 Декабря 2011, 00:10:42 »

В ходе дисскуссии, ИМХО, происходит перемешивание целей. Предлагаю разделить:
1. Бизнес Цели . Достигаются только бизнес-процессом и собственно работой сотрудников.
2. Цели, достижимые ИТ-системой.
Мой опыт говорит, что постановка перед ИТ-фирмой задач об увеличении эффективности работы или продажа под это дело ПО (не АСУТП, понятно) - фикция. Может и есть примеры обратные - не видел.
Исходя из этого же оценить прямой эффект от внедрения ИТ-системы на предприятии удается редко.
Выход:
- оценить эффективность и перестроить бизнес-процесс;
- при необходимости обеспечить новый бизнес-процесс ИТ-поддержкой. А вот здесь уже вполне нормально посчитать и оценить в деньгах "Переделать старую" vs "Купить новую или создать новую".
-----------------------------------
Цели для бизнес-процесса звучат в натуральных показателях к определенному сроку. "Достичь объема продаж в 10 млн. тугриков к 26.12.2013."
Цели для ИТ-системы звучат гораздо сложнее и как правило сводятся к поддержать бизнес-процесс в рамках его временных ограничений и обеспечить корректную и своевременную аналитику по процессу.
-----------------------------------
В ходе внедрения достаточно часто перемешивают цели и ИТ-специалисты начинают решать обе задачи, т.к. бизнес сам не в состоянии справиться с первой, но самого разделения целей это не отменяет.

10

Управление Проектом / Re: Планирование трудозатрат по написанию документации

« : 26 Декабря 2011, 23:15:53 »

ТЗ лучше считать исходя из предполагаемой сложности. Оценить сколько будет в ТЗ тех самых "3-4 несложных варианта использования,".
При этом важно учесть 2 вещи
1. Сложность растет нелинейно, т.е. если в ТЗ будет 10 вариантов использования, то их связывание между собой займет сравнительно мало времени. При 100 вариантах в связанной системе требуется уже время на притирку их друг к другу. Тут сложно точно оценить время, но например можно предположить: "увязка 5 вариантов между собой = 1 вариант использования по времени"   
2. Документ требует времени на оформление. Это СУЩЕСТВЕННОЕ ВРЕМЯ.
3. Молодой специалист все равно переоценивает свои силы и заложит мало времени на написание ТЗ

В связи с этим предлагаю практически:
1. Метрики и оценки:
-3-4 несложных варианта = 1 ч-день
-1 сложный вариант использования = 1 ч-день
-1 средней сложности вариант использования = 0.5 ч-дня
- увязывание 5 несложных вариантов = 0.25 дня.
- увязывание сложных вариантов считается
- оформление документарное 10 несложных вариантов использования = 1 ч-день
- коэффициент "мысленного упрощения" (на него надо в конце умножить) = 1.33
2. Важно - это МОИ оценки данных метрик. Ваши могут, и скорее всего будут, немножно другими.
3. Далее
 - разбиваем предполагаемое ТЗ на варианты использования
 - учитываем сложность
 - учитываем оформительство
 - умножаем на коэффициент
Вуаля )))
Что не учтено в модели - время на согласование и переделывания. Тут все зависит от организации работ в вашей конторе. Время за чистовик - тогда их надо учитывать. Как, сколько стоит? Вам виднее изнутри.

11

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

« : 26 Декабря 2011, 21:44:34 »

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

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

12

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

« : 26 Декабря 2011, 19:14:13 »

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

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

13

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

« : 26 Декабря 2011, 17:06:50 »

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

По чеку: ориентировался на рисунок.
ИМХО, По остальным вопросам: опирать при моделировании необходимо на:
1. Границы описания - юзкейсы. Юзкейс по А. Кобурну "Эффективное написание юзкейсов": Экземпляр юзкейса (сценарий) это последовательность действий, выполняемых в системе, которые позволяют получить результат, наблюдаемый для актера этой системы, юзкейс определяется как совокупность всех своих сценариев. (конец цитаты). Ключевое слово для меня: позволяет получить результат для актера системы. Покупатель приходит за покупкой в магазин в данном случае может быть границей моделирования. Все сущности я стараюсь протягивать из вне модели (т.е. деньги покупатель приносит с собой, цены на товары и ассортимент тоже входные даннные (за границами моделирования), ну и так далее...
2. Все объекты приходящие в юзкейс снаружи должны из него выйти в том или ином виде (тоже физичном). Такой "закон сохранения материи" )))

14

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

« : 26 Декабря 2011, 16:52:30 »

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

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

На самом деле книга остается в модели; может, например, перейти в два потока: идентифицированные книги и неидентифицированные.
Читательский билет на входе и читательский билет на выходе. Внутри есть функция по его модификации, но сущность не меняется. Если запись ведется в отдельном журнале или как отдельная сущность вводится в компьютер, то ее можно учитывать в моделировании как порожденную.

Есть более изощренные моменты:
контекст: абонемент библиотеки
- вход: читательский билет
- выход: электронный формуляр читателя
- процесс: идентификация читателя

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

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

Аналогично предыдущему. Важно! Читательский билет возвращается читателю, но по нему определен формуляр. На вход идут: читательский билет, база формуляров. Управляющим: правило определения. Выход: читательский билет - обратно читателю надо направить (по идее его надо провести за рамки системы), формуляр читателя.

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

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

Внимание вопрос к аудитории: Скажите, пожалуйста, а как вы объясняете, производите обзор и рецензию в подобных случаях? Какие правила и проверки вы используете? Спасибо

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

15

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

« : 26 Декабря 2011, 15:10:28 »

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

Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система

Что тут правильно или не правильно?

По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".