Обеспечиваем соответствие ИС потребностям пользователей

bpmnforum.ru » Основной » Диаграммы BPMN

Обеспечиваем соответствие ИС потребностям пользователей

17 сообщений от 3 голоса

Начато: 12 лет назад пользователем Андрей Попов
Последний ответ: Андрей Попов

Метки:

Андрей Попов
Участник
Рейтинг:10
Здравствуйте!
Предлагаю тему задания для подготовки ко второму семинару. Предлагаю присоединиться не занятым другими темами участникам семинара, планируемого на 1.10, и всем желающим. Описание в прикрепленном файле. Область - информационные технологии, удовлетворение запросов пользователей к информационной системе. Описание в прилагаемом файле. Коротко изложить не получилось, хотелось привести больше существенной информации. Если будут предложения - можно и упростить, и усложнить задачу. Если есть неточности, пробелы - можно исправлять постановку.
Спасибо за внимание.
Файлы
Обеспечиваем_соотве (47.5 KB, 34 downloads) 12 лет old
Опубликовано 12 лет назад #
Pavel-Smirnov
Участник
Рейтинг:195

Андрей!
Весь день и с разных компьютеров пытаюсь открыть (сохранить) ваш документ. Никак не получается (хотя все остальные документы с этого сайта открываются "на ура", вот странно). Пожалуйста, пришлите ваш документ на мой электронный адрес: smirnjv@tkman.ru
Спасибо.

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

Цитирую Pavel-Smirnov:
Андрей!
Весь день и с разных компьютеров пытаюсь открыть (сохранить) ваш документ. Никак не получается (хотя все остальные документы с этого сайта открываются "на ура", вот странно). Пожалуйста, пришлите ваш документ на мой электронный адрес: smirnjv@tkman.ru
Спасибо.

Добрый вечер, Павел. Документ выслал вам на почту, но пришел автоответ - smirnjv@tkman.ru не найден в почтовой системе получателя. Проверьте, может адрес не тот?
Сам тоже свой файл из ссылки открыть не могу.
Может кириллическое название? Нет у меня никакого опыта жизни в форумах)). Кто-нибудь посоветует? Заранее благодарен.

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10
Попытка номер два, тот же файл, но теперь docx и короткое имя на латинице. Вдруг получится?
Файлы
Task1.docx (22.7 KB, 26 downloads) 12 лет old
Опубликовано 12 лет назад #
Pavel-Smirnov
Участник
Рейтинг:195

Андрей!
Документ task1.docx скачался без проблем. Будем смотреть.
Предложенный вами процесс интересный, но, на мой взгляд, объемный. Напомните, пожалуйста, задание, которое нам задал Анатолий, - это задание нужно выполнить к началу второго тренинга или к окончанию всех трех тренингов?

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

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

Опубликовано 12 лет назад #
Анатолий Белайчук
Хранитель
Рейтинг:498

Коллеги

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

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

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

После того, как проработаете процессную архитектуру, решите какой (какие) процессы вы хотите проработать, а какие оставить "черными ящиками".

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

Добрый вечер!
Немного неожиданное развитие, хотя интересное. Изначально не подразумевались ошибки системы и вопросы управления инцидентами, вроде бы поставленная задача не вписывается в понятие инцидента по ITSM. Сервис-то продолжает нормально работать, нет ошибок, проблем, инцидентов - просто пользователь вдруг захотел большего, чем у него было вчера, или, может, SLA захотел поменять. А интересно то, что мы в целом ряде случаев действительно можем прийти в предложенный к анализу процесс как раз из процесса управления инцидентами. Запускающее событие, наверное, поменяется, участники, процедуры планирования могут немного сдвинуться. Если решением инцидента будет определен один из четырех возможных по условиям задачи путей, то наша задача может стать частью процесса управления инцидентами, одной из его ветвей.

Опубликовано 12 лет назад #
Pavel-Smirnov
Участник
Рейтинг:195

ОПРЕДЕЛЕНИЯ
Инцидент (incident) - любое событие, не являющееся частью нормальной работы услуги, ведущее/ способное привести к остановке услуги или снижению уровня её качества
Запрос на Изменение (RFC) - экранная или бумажная форма, используемая для записи детальной информации о предлагаемом запросе на изменение какой-либо CI (сonfiguration Item - конфигурационная единица) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта IT-инфраструктуры.

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

Цитирую Андрей Попов:
Если решением инцидента будет определен один из четырех возможных по условиям задачи путей, то наша задача может стать частью процесса управления инцидентами, одной из его ветвей.

Опубликовано 12 лет назад #
Анатолий Белайчук
Хранитель
Рейтинг:498

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

По поводу вытекания одного из другого: пользователь сплошь и рядом не знает, бага это или фича. Все что он видит - система ведет себя не так, как ему бы хотелось. Если "как хотелось" совпадает с тем "как задумано", то это бага. Если нет - фича, и требуется доработка. Но выяснение этого требует некоторых усилий - например, надо свериться с документацией. Эта работа делается в рамках инцидента.

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

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

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

Цитирую Pavel-Smirnov:
Сомнительно, что второе может вытекать из первого.

Добрый вечер! Очевидно, я неправильно выразился, чем подтолкнул коллег на навигацию по ITSM и ITIL. Я имел в виду, что процессы обучения, настройки системы, локальные и дистрибутивные доработки могут понадобиться не только в нашем примере, но и, например, могут вызываться из процесса управления инцидентами. Учить можно тех, кто своими действиями ломает систему, настраивать можно тех, кто избытком или недостатком прав создает проблемы, инциденты на уровне кода можно убирать доработками. Это все интересно, но наше обсуждение уходит за рамки наших целей.

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10
Добрый день!
На простейшем уровне нарисована первая версия. Сразу же вывод - много, громоздко, не читается. Притом, что задача была упрощена до предела по сравнению с тем, как она вертится в реальной жизни. Может быть, можно использовать при составлении текстового регламента процесса, или для поверхностного анализа. Невозможно использовать для автоматизации или для системного анализа.
Напрашивается необходимость взаимодействия независимых процессов. Здесь должен работать Help desk (принимать от пользователя все проблемы и пожелания, решать проблемы с простым обучением и настройкой), здесь есть бюджетный процесс (можно не разворачивать), здесь есть производственный процесс третьего лица (наверное, не следует разворачивать, хотя в частном случае он нам известен), есть внутренний планируемый производственный процесс различных модификаций ИС, есть процесс разворачивания и тестирования различных модификаций ИС (в том числе и не перечисленных в нашем примере). Надо попробовать.
Файлы
Task1v01.bpm (39.7 KB, 26 downloads) 12 лет old
Опубликовано 12 лет назад #
Анатолий Белайчук
Хранитель
Рейтинг:498

> много, громоздко, не читается

Надо выполнить структурную декомпозицию. Проще говоря, разбить на подпроцессы.

> Напрашивается необходимость взаимодействия независимых процессов

Сложность процесса (большое число задач) не является аргументом для выделения независимых процессов. Собственные триггеры и асинхронное выполнение - являются. Например, в данной задаче я бы разделил процесс, связанный с заявкой на доработку и процесс, связанный с релизом. Обычно заявки, пройдя определенную процедуру первоначального анализа, получают приоритет и встают в очередь. Когда же мы начинаем работу над релизом, мы просматриваем заявки и отбираем какие-то из них для включения в релиз. Паттерн "внутренний заказ" - http://mainthing.ru/ru/item/150/

Опубликовано 12 лет назад #
Pavel-Smirnov
Участник
Рейтинг:195
Хочу предложить свой вариант (правда, - недоделанный :( )
Файлы
RFC.png (125.7 KB, 9 downloads) 12 лет old
Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

Добрый вечер! Простите, что почти устранился от собственной задачки, но как назло - работа зовет в неподходящий момент, мешает саморазвиваться))).
Анатолий,
Спасибо за комментарий, повод задуматься. Но релизы - вообще не мой случай. Надеюсь, я правильно понял, о чем именно идет речь. Я не разработчик, я использую внешний лицензионный продукт, я (Служба Заказчика и Внутренняя Сервисная Служба) не собираю и не выпускаю релизы ни при каких условиях. Каждая заявка, точнее, ее решение - штучный товар. Релизы же периодически выпускает моя ВСС. Правда, она иногда использует при их выпуске заказанные и оплаченные мной дистрибутивные доработки, но это уже нюансы. Зато при выпуске очередного релиза я могу иногда получить новый полезный мне функционал, который был фактически оплачен каким-то другим несчастным. Про релизы - отдельный вопрос. Есть ведь еще задача периодически переходить на новый релиз. Но по-моему она (и почти вся моя задачка) весьма изящно была решена на одном из Ваших тренингов, материал есть на bpmntraining.ru.
Павел,
Спасибо за участие, вижу интересные для себя моменты в Вашем варианте, но его сильно портит незаконченность. Местами очень непонятно, что же там будет. Буду ждать завершения, если оно последует.

Опубликовано 12 лет назад #
Анатолий Белайчук
Хранитель
Рейтинг:498

Цитирую Андрей Попов:
я использую внешний лицензионный продукт

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

я (Служба Заказчика и Внутренняя Сервисная Служба) не собираю и не выпускаю релизы ни при каких условиях. Каждая заявка, точнее, ее решение - штучный товар. Релизы же периодически выпускает моя ВСС.

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

Опубликовано 12 лет назад #
Андрей Попов
Участник
Рейтинг:10

Анатолий, извините, конечно же я напутал с терминологией опять. Я же назвал их изначально Локальной и Внешней. Должно быть как в задачке ЛСС и ВСС. В скобках должно было быть: (Служба Заказчика и Локальная Сервисная Служба). Локальная, ЛСС - не выпускает, и ее функции зажаты специальными правилами и соглашениями - только настройки и локальные доработки. Внешняя, ВСС может делать вообще все, в том числе, выпускает релизы и еще как!!!

Опубликовано 12 лет назад #

RSS лента этой темы

Ответ

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

bpmnforum.ru

Обеспечиваем соответствие ИС потребностям пользователей

Файлы

Файлы

Файлы

Файлы

Ответ