Как стать автором
Обновить

Комментарии 5

Привет!
Спасибо за статью и интересный опыт.

Проект уже завершен или еще «в работе» и сданы какие-то первые кусочки работ?

Мог бы ты поделиться опытом, например, в виде отдельной статьи, внедрения процесса «Управление конфигурациями», использования Insight — Asset management в частности.

Интересен именно подход к планированию работ по внедрению, Вашей первичной прогнозной оценке предстоящих работ, процесс выявления ключевых активов и всех составляющих характеристик.
Существовала ли до этого в Банке CMDB?
— Если да, то как Вы ее оптимизировали/актуализировали (или это делалось на стороне Заказчика, а Вы уже работали с тем, что дали)?
— Если нет, то очень интересен процесс выявления этих активов — как Вы это делали, сколько заняло времени, каких специалистов(роли) привлекали к данной активности?

Заранее спасибо!
Хорошая идея про отдельную статью насчет Asset management. Краткие ответы по пунктам:
1) Проект сдан, сейчас фаза саппорта и уже доделывания/допиливания разных процессов
2) В банке была CMDB, мы давали рекомендации по ее ре-организации в продукте Insight Asset management, посмотрели на существующую структуру, сделали аналог +- в Insight и начали наполнять, параллельно вывели все это с условиями на портал чтобы можно было запросы сразу к ассетам линковать
3) Сейчас еще планируем поставить Discovery, чтобы автообновление было ассетов, будет отлично летать. Когда анализировали и собирали данные привлекали начальников разных отделов в IT департаменте — инфобез, инфраструктура, саппорт, развитие. В основном с ними общались, им задавали вопросы а дальше они уже собирали информацию внутри по своим системам, экселькам и людям
Спасибо за ответ, успехов Вам в реализации!
Тема и правда интересная.
Евгений, привет!

Спасибо за статью, отличный опыт! Даже зарегался специально, чтобы комментарий написать)

Тоже интересно про:
1. Riada (теперь они Mindville) Insight, мы сами ее используем сильно шире чем просто CMDB
2. Каким образом настроили спринты\приоритизацию тасков из бизнес-требований и Change request из поддержки для разработчиков?

ps. пометка про ">на смену ей была разработана Omnitracker". Все-таки Омник совершенно отдельный продукт (кстати, он как и Jira вырос из трекера задач). В Европе его развитие никакого отношения к угасанию HPSD не имело, а в России очень удачно совпало — за счет этого он и зашел на рынок
Пометка принимается, наши все энтерпрайз клиенты либо переезжали с HP на Омник, либо сразу с HP на Atlassian.

По вопросам:
1) У нас есть в работе кейс, где используем Insight для риск менеджмента, а внутри используем как контакт книгу, сразу можно связать с проектами, данными, запросами человека
2) Это вопрос на который нет ответа в прошлом времени) пока еще в работе, так как наша сфера ответственности напрямую на включает департамент разработки, он немного вынесен за поддержку. Но если говорить про то как есть и с чем мы работаем то: бизнес требования приоритезируются прокси стейкхолдерами, а-ля продакт оунер в праведном IT мире. Приходят они также через сервис деск и по внутренним каналам. После того как они приоритезированы, они попадают дальше на декомпозицию и работу. ПО Change request все проще, написано 40 скриптов на Power Script которые обрабатывают типовые ченджи, создается типовой чендж А и сразу к нему 8 связанных между собой задач на соответствующие линии поддержки. Ну и мы написали плагин чтобы забивать порядок задач marketplace.atlassian.com/apps/1221874/task-order-for-jira?hosting=server&tab=overview

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

Публикации

Истории