Ого

То что надо

Спасибо

пожалуйста)

В понедельник в ДА?

да

Это значит на метро ехать, ок.

вы о чем это тут договариваетесь?! %)

для проектирования информационной модели на бизнес и системном уровне крайне рекомендую изучить SID, от TM Forum.  
Хоть уклон для телекома, но легко переиспользуется в любой области. Все зависит от уровня абстракции.  
Тут источник https://www.tmforum.org/information-framework-sid/
Вот сама модели и материалы https://cloud.mail.ru/public/KtXY/xt8x4VTYc (правда не знаю, ругаются ли за такое распространение:) )
тут нашел материалы на русском http://web-local.rudn.ru/web-local/uem/iop_pdf/11-Samuilov.pdf

встреча сообщества у нас плановая =)
https://spb-coa.timepad.ru/event/382661/

Archimate, SID - опять много веточек. =) Кто во что горазд =)

Vyacheslav, это именно инструмент или нотация? Кто и для чего разрабатывал? Если инструмент, на основе какой нотации или принципа моделирования?

Это инструмент. На основе UML, элементы представлены в виде
классов, отношения между ними – в виде ассоциаций.  
это референтная модель данных, разработанная TM Forum с целью стандартизации используемых в отрасли онтологий, понятий, достижение договорённости о взаимосвязи сущностей, информационных потоках. Предполагается, что следование этой референтной модели разработчиками информационных технологий для электросвязи обеспечит более естественную и прозрачную интеграцию разных решений, позволит снизить риски онтологических ошибок в таких интеграционных проектах.

Коллеги, кто-нибудь внедрял Управление изменениями как процесс? Затрудняюсь четко определить, какие запросы должны идти как "Изменения", а какие - можно в операционку отдавать на сопровождение по упрощенному процессу. Т.е. точка входа одна - а дальше нужно распределять по веткам - либо на ЖЦ Изменения, либо это просто ошибка, и надо как инцидент провести, либо это непонятная штука. Вот где граница между "поменять цвет вот этой кнопки" и "внедрите мне CRM" - пока не понял.

В идеале - может кто-то видел или писал классификатор видов изменений, и условия их прохождения по жизненному циклу?

Классификатора не писала. По идее можно делить по трудоёмкости и количеству задействованных сотрудников/ команд.

А зачем делить?

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

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

Запрос
Запрос внешнему поставщику
Идея
Изменение
Инцидент
Инцидент ИБ
Конфигурация
Обращение
Проблема
Работа
Уровень услуг