16

Для всех / Re: Описание сервисов, предоставляемых ИТ-инфраструктурой

« : 29 Марта 2016, 20:07:57 »

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

К бизнес-анализу Вас точно никто не отсылает. Ваши исходные вопросы

Возможно, автору топика стоит конкретизировать свой вопрос. Т.е. мне не до конца понятно, что он всё-таки ищет (и что подразумевается под желанием "описывать сервисы") :
1. Эффективную "рисовалку" ИТ-инфраструктуры?
2. Конкретный пример как рисовать ИТ-инфраструктуру в EA\на UML?
3. Инструмент для автоматизации процессов ITSM (не только "рисовалку")?

Моё предположение в том, что интересовал его 3й вариант.
С тем что в EA  можно нарисовать ИТ-инфраструктуру - не спорю. Но это не делает  EA 3-м вариантом.

17

Для всех / Re: Описание сервисов, предоставляемых ИТ-инфраструктурой

« : 29 Марта 2016, 09:48:07 »

Возможно я ошибаюсь, но вопрос был не совсем про бизнес-анализ и UML, а скорее про инструмент для поддержки процессов предоставления ИТ-услуг.
В этой области есть куча специализированных инструментов от очень дорогих типа HP OpenView до бесплатных. Можно погуглить что-нибудь типа "ITIL Tool", "ITSM Tool" итп.
На одной из моих прошлых работ мы это делали просто в нескольких таблицах на SharePoint.

18

Примеры / Re: Тестовая диаграмма

« : 09 Марта 2016, 12:02:15 »

Как бы вы оценили степень моего знакомства с нотацией от 0 до 10, где 10 - гуру?

Сам уже довольно давно последний раз АРИСом пользовался, так что не берусь судить. От вашей диаграммы, есть ощущение, что вы торопились.

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

  Моя мысль была в том, что в диаграмме есть логическая ошибка. Оператор AND на вашей диаграмме это не только точка ветвления параллельных потоков управления (к Подготовить спецификацию и к Отправить материалы), но и точка слияния потоков управления (от Дата поставки соблюдена и от Дата поставки не соблюдена). Т.к. события взаимоисключающие, то слияние никогда не произойдёт. Соответственно, всё что находится за этой точкой не выполнится никогда. Ошибка очень распространённая. Этот кусок диаграммы нужно переделать.

Да это одно и тоже. Как его вынести в отдельный процесс? Можете скинуть ссылку на пример?

Мысль была в том, что, возможно, стоит разбить диаграмму на несколько. Т.е. сделать отдельную диаграмму для процесса "Возврат материалов", а из основной диаграммы ссылаться на неё. Например, как на картинке http://www.e-biblio.ru/book/bib/Sinergia/restruk-bp/sg.files/image082.jpg. Это упростило бы диаграмму. Как вариант, диаграмму можно оставить одну, но структурировать её так, что логика возврата материалов будет описана в единственном месте.

В целом, на почитать - рекомендовал бы Репина и Елиферова. Например здесь: http://www.e-biblio.ru/book/bib/Sinergia/restruk-bp/sg.html. Там много текста, но систематично. В т.ч. и про типовые ошибки.

19

Примеры / Re: Тестовая диаграмма

« : 07 Марта 2016, 12:51:19 »

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

С моей точки зрения, есть такие вопросы к диаграмме:
1. Смущает кусок, начинающийся с событий "Дата поставки соблюдена" и "Дата поставки не соблюдена".
- Ветвление происходит через ХOR, а слияние через AND. Т.е кусок после слияния недостижим по определению.

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

3. События "Возврат материалов" и "Возврат материалов поставщику" это одно и то же?
Если одно и то же, то возможно, структура диаграммы не понравилась.  Кусок с возвратом материалов, 2 раза продублирован на диаграмме. Возможно стоило вынести это в отдельный процесс.

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

20

Бизнес-анализ и Целеполагание / Re: Как описывать алгоритмы в сценарии (use case)?

« : 20 Января 2016, 11:55:48 »

В случае соответствия правилу, переход в п.3

Обычно такое не пишут. В ВИ есть специальный раздел "Альтернативные потоки" или "Исключения"

21

Задачи студентов / Re: Правильность создания IDF0 Школьной библиотеки

« : 18 Января 2016, 14:50:42 »

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

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

Про деньги, кстати, тоже интересный вопрос. Если библиотека платит налом, то да у нас будет стрелка деньги (но тогда возможно имеет смысл сделать для библиотеки ресурс "Деньги"). В реальной жизни, скорее всего деньги идут безналом со счёта школы. Т.е. из библиотеки в бухгалтерию школы идёт некая служебная записка на оплату книг + обычно счёт от поставщика. Т.е. стрелок с деньгами тогда не будет. Будут стрелки с документами.

22

Задачи студентов / Re: Правильность создания IDF0 Школьной библиотеки

« : 18 Января 2016, 13:20:05 »

Заказы поставщику и деньги поставщику это выход, книги от поставщика и товаросопроводительные документы это вход.

23

Задачи студентов / Re: Правильность создания IDF0 Школьной библиотеки

« : 17 Января 2016, 18:26:06 »

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

Декомпозиция 1го уровня мне очень не нравится.
Поиск в картотеке как процесс верхнего уровня? Картотека - это только инструмент. Это примерно, как описывая завод сделать процессы верхнего уровня "Работа с компьютером" и "Остальные процессы". Т.е. непосредственному использованию инструмента - не место на верхнем уровне.

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

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

По поводу того какие процессы писать на верхнем уровне - я бы рекомендовал сосредоточиться на обслуживании читателей. Если вы не библиотекарь, то про остальное вы знаете очень мало. Т.е. должно быть что-то типа "Регистрация читателей", "Приём книг от читателей", "Выдача книг читателям" можете глубже покопать, например "Претензионная работа" (борьба со злостным невозвращателями книг.


PS: Тема бизнес-процессов библиотек очень распространена в качестве курсовых работ. По ней можно найти много информации и на этом форуме и в интернете например вот. Посмотрите - многие моменты станут яснее.

24

Задачи студентов / Re: Правильность создания IDF0 Школьной библиотеки

« : 17 Января 2016, 17:36:03 »

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

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

И да, как уже отмечал Log  с т.н viewpoint лучше определиться сразу. Иначе размер вашей модели может устремится к бесконечности.

25

Варианты Использования (Use Case) / Re: Как отобразить на ВИ требования к вариантам развертывания?

« : 13 Января 2016, 15:27:32 »

Поток данных направлен от среды к кейсу, а от кейса - пользователю, который в этот момент совершает действия вроде "слушаю" или "смотрю

Насколько я помню ВИ, не может быть никакого "потока данных" от актора к ВИ и обратно. ВИ это цель Актора относительно системы. Не может быть потока данных от Актора к Цели. Цель у Актора либо есть либо нет.

С моей точки зрения, вопрос так как его ставит автор топика  скорее всего не имеет решения. Нельзя при помощи ВИ разрисовать структуру и поведение системы (я понял вопрос автора именно так). Нужно использовать другие типы диаграмм: контекстную, data-flow diagram, robustness diagram, component diagram, deployment diagram, возможно другие.

26

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

« : 16 Октября 2015, 21:04:55 »

Вроде бы вы сами ответили на свой вопрос

Только в группировке по стране, наверное, логично чтобы 2м уровнем шла группировка по головной организации. А в группировке по головной организации возможно будет полезна группировка по стране 2м уровнем.
Или вопрос был не об этом?

27

Задачи студентов / Re: как на sequence diagramm показать activity diagramm

« : 13 Октября 2015, 17:34:43 »

На эту тему есть ещё SDL диаграммы, только это не UML

28

ПО Аналитика / Re: Помогите с выбором инструмента для описания БП

« : 05 Сентября 2013, 14:19:27 »

Про показатель:
Предлагаемый показатель "высвобожденные ЧЧ за единицу времени работы команды" лично мне не нравится (не говоря уже о том, что я вообще против того чтобы ИТ отвечал за ранжирование)

- 30 ЧЧ высвобожденных в каком-нибудь малозагруженном подразделении (скажем АХО) не равны 30 ЧЧ высвобожденных в каком-нибудь перегруженном месте (условно в колл-центре).
- Многие задачи вообще не высвобождают ЧЧ, при том что они объективно полезны. Например, что-то направленное на улучшение клиентского сервиса
- ЧЧ разных людей, как минимум, по разному стоят.
- Некоторых людей в организации лучше не огорчать. Даже если высвобождаемые ЧЧ у их проекта плохие.
- Заказчик склонен преувеличивать высвобожденные ЧЧ, чтобы сманипулировать результатами ранжирования. Верификация заявляенных ЧЧ нетривиальна и может требовать трудоёмкой эксперитизы.
- При таком подходе функциональность ваших решений будет неуправляемо "разбухать", что увеличит затраты на поддержку, затруднит делание Больших Проектов и снизит другие KPI ИТ (количество дефектов за период, например).
- Если заведёте такой KPI то в следующем отчётном периоде его настоятельно попросят повысить процентов так на 15
- Кстати, с увеличением размера команды этот показатель, скорее всего, снизится


Про увеличение команды:
Есть у меня теория, что поток мелких реквестов обычно интересует бизнес только на
предмет занять чем-нибудь команду между деланием Больших Проектов, исправления багов и задачек, которые реально интересует топов. Сделает команда 30 мелких реквестов или 50 бизнес волнует очень мало. Для компании в целом они ничего принципиально не меняют - высвобожденные ЧЧ будут потрачены на ещё какую-нибудь малозначимую хрень - не только вам веселее работать в большой команде. Предположу, что именно поэтому эту задачу у вас заделегировали чуть ли не на уровень ИТ. Т.е. наращивание описываемого вами KPI - это плохое обоснование для увеличения команды. Лучше это обосновывается под какой-то проект который топам заметен.


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

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

• - Специальный комитет, который утверждает [план ближайших работ]. Чем более влиятельны его участники тем лучше. На моей прошлой работе туда даже CEO входил (компания среднего размера - ок.1000 сотрудников). Подразделения-заказчики защищают свои доработки перед Комитетом. CIO, естественно, был участником комитета.
• - В большой компании, где я сейчас работаю, запросы поступают в особое бизнесовое Подразделение-Координатор, которое, среди всего прочего, курирует развитие нескольких взаимосвязанных систем. Подразделения-заказчики договариваются с менеджерами этого подразделения. Подразделение-координатор путём переговоров с ИТ, формирует скоуп следующего релиза системы.
• - Слышал про систему жетонов. Подразделениям-заказчикам раздаются жетоны из каких-то общих соображений. Эти подразделения покупают на эти жетоны время ИТ-подразделения. Тут много подробностей не знаю, сам слышал только рассказы.

Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.

29

ПО Аналитика / Re: Помогите с выбором инструмента для описания БП

« : 03 Сентября 2013, 20:29:45 »

Действительно, мы как то съехали с темы. Давайте лучше поговорим про то, что 3DS Cradle это, кстати ещё и идеальный инструмент выстраивания взаимодействия бизнеса и ИТ

30

ПО Аналитика / Re: Помогите с выбором инструмента для описания БП

« : 03 Сентября 2013, 17:39:32 »

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

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