У меня от Prince 2  из важного-применимого только триумвират группы управления остался в сухом остатке

В ИТ сейчас большой спрос на Agile-подходы. Лучше в этом направлении,  на мой взгляд

А у меня акцент на продукты

Игра «Scrum&Lego»

Когда: 16 ноября 2019 года

Где: г. Екатеринбург (точный адрес будет известен чуть позже)

Описание:

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

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

Стоимость:

2000 руб. при оплате до 31 октября включительно
2500 руб. при оплате с 1 ноября

Для участников группы по промокоду agilewithlove стоимость останется неизменной – 2000 руб.

Количество мест: 40

Зарегистрироваться на игру, почитать о ней более подробную информацию, а также посмотреть отзывы с прошлого мероприятия Artsofte.Digital можно по ссылке:
https://eventwithlove.timepad.ru/event/1092608/

#AgileWithLove ; #Екатеринбург; #платно; #Agile_Ekb: #управлениепроектами; #полезное; #управлениебизнесом; #EventWithLove; #agile; #scrum; #БизнесИгра; #EventWithLove; #команда; #командообразование; #полезнаяигра

Коллеги, а есть у кого практика аудита ИТ инфраструктуры и/или сервиса при приёме на ИТ-аутсорсинг. Бест практис и т.д.? Куда копать, чего смотреть?

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

Когда мы строим систему,  то идём по цепочке Требования-ТЗ-Реализация. Когда мы принимаем то, что кто-то ранее нареализовывал, то смотрим железки и/или систему/сервис, частично документам их. Технические подразделения пишут техническую документацию - частично эксплуатационную, частично более высокого уровня. Но что насчёт фиксации требований при таком обратном подходе?

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

Тут надо ещё смотреть куда услуга ориентирована - на внутреннего клиента или на внешнего и иметь ввиду, что подсчет услуги построенной на виртуальной инфре сложнее. В VMware виртуальное и физическое железо это не связанные сущности через деньги, но тем не менее среднюю стоимость CPU, RAM, HDD, лицензия на ядро и др. - некоторые считать научились. Если услуга наружу, то надо считать людей, кто занят в ее предоставлении (FTE, ФОТ), оборудование для рабочих мест, аренда офиса и техники.  Не лишним будет поднять доходные контракты

Вот тут речь сразу об услуге, а по мне так это уже высокий уровень зрелости и состояние to be. As is это реестр конфигурационных единиц с минимальным уровнем связей и пониманием что где работает. Минимальный обратный проход даёт нам: 1. Реестр конфигурационных единиц  2. Техническое описание - как оно  настроено. 3 Примитивный SLA (иногда на уровне отдельных конфигурационных единиц) - доступность 24×7, перерыв доступности не более 8 часов в месяц.

Ответа на вопрос почему это так настроено (т.е. изначальных требований) - нет. При этом есть ощущение,  что не плохо бы ответить на этот вопрос - формализовать требования. Просто с точки зрения рисков.
Например, есть АТС и описание её настроек.  А есть не актуальное  бизнес описание прохождения через неё входящего потока звонков. И тут я перестаю понимать - входит это в SLA или нет. Чтобы,  например, в рабочее время соблюдался один сценарий, а в не рабочее время - другой сценарий. При этом общий SLA про 24×7 и не более 8 часов недоступности - соблюдается.

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

Примитивный SLA намекает о том, что получить стоимость услуги "на дату по запросу" не работает. Скорее услуга продается формально мешком за некий фиксированный объем, внутри которого перезаложены и регулярные платежи и разовые. Колебания +/- скорее всего не учитываются. Пример с АТС удачный, продолжая мысль - волбще надо считать такие затраты в том числе и на настройку канала, через который трафик ходит через АТС, хотя это и разовые затраты. Но мне кажется, тут главное не как правильно получить честную стоимость, а как надо сделать для продажи услуги провайдеру:). Поверьте, никто в такие детали вдаваться не будет. Скорее всего поднимут  договор на аренду канала, если он внешний и плюсанут к услуге остаток от освоенного. Если канал свой, - никому не интересно, что там ИТ делали.

Полистал ITIL 4 - то о чём я спрашиваю чётче всего описано в разделе 5.2.2 бизнес анализа (стр 114) - как неожиданно :) правда там рассматривается нормальное применение - начиная с планирования. А не воссоздание сценария на основе имеющейся конфигурации ) И относительно железнячной инфраструктуры это всё, конечно,  относится к довольно высокому уровню зрелости.

Все правильно, ITIL говорит как надо, а в реальной жизни все делается по понятиям или как договоришься. Давление сроков часто не даёт выполнить работу канонически

То о чем ты сейчас спрашиваешь называется транзишен

я могу как освобожусь набросать план

ибо  есть богатый опыт хождения по подобным граблям

👍

так...

Транизишен план:
1. Due diligence
В рамках фазы пишется боевой план и собирается транзишен команда
2. Тrаnsition (поэтапно с milestones )
Задача: принять дела
Результат:   проверенные документы,  команда получила стартовые знания для начала суппорта
3. Shadow support - Вы наблюдаете за тем, как текущая команда осуществляет поддержку. То есть при вас, народ сидит и обрабатывает тикеты. Обычно на этом этапе вскрывается весь реальный пипец, который отгребает текущая команда поддержки.
4. Reverse shadow support -Вы  при текущей команде поддержки пытаетесь обработать тикеты. Они проверяют и подсказывают.
5. GoLive (дата)
6. Baselining  1-3 месяца
В рамках  этого периода обычно расчитываются бюджеты и модели оплаты.

Задачи и подводные камни.
1. Смотрим в контракты и ищем  SLA и  подводные камни
3. Запрашиваем процессные документы  
Обязательные общие документы:   Icident Managment Process, Problem Managment Process, Knowledge base, документ описывающий интеграции отдельных частей, документ описывающий общую инфраструктуру
Возможны:  Ranbook, SMDB,
Напрягаемся если :  очень старые документы,  каких-то документов нет, документы непонятны(с большим количеством воды, написаные на отьебись).  Обязательно при подготовке транзишен плана закладываемся на переработку документации. Ни разу не было, чтобы дока была в порядке.

2. Запрашиваем историю тикетов за 3 прошлых месяца
  - Смотрим на тренды
 - Ищем узкие места в инфраструктуре и процессах
-  Проверяем как исполняются  SLA (могут всплыть внутренние договоренности, незафиксированные sla и много чего ещё:  "ну усегда же работали так")
3. Проверка инфраструктуры
- выясняем  кто, кроме нас отвечает  за инфраструктуру  и выясняем их контакты, зоны отвественности, график  работы, график отпусков, способы связи.   Согласуем матрицу ответсвенности.  Проверяем, как это отражено в контрактах и процессных документах.   Обязательно знакомимся с соседними командами, и  предупреждаем их, что начиная с  GoLive  за некоторою зону отвечаем мы
- выясняем  стандартный график бекапов (пытаемся проверить: а вообще валидны ли бекапы)
- выясняем meintanance windows, frozen zone  и тд
- запрашиваем доступ к системам мониторинга
- проводим инвентаризацию

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

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

5. Проверка доступов
-  выясняем сколько нам нужно учеток, как скоро делаются, кем делаются, нужны ли доп. лицензии ( и  таки кто за них платит)
-  получаем учетки ( идеально перед этапом Reverse shadow support, реаьно за 1-2 недели до GoLive (дата) . Если этого не случилось- эскалируем.  )

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

7. Проверка  текущего аутсорсера
Выясняем почему слили текущего  аутсорсорсера (дорогая услуга,  поругался с топами, работал не эффективно и тд.).
Причем слушаем команду, клиентов услуги и специалистов самого аутсорсера.  Информация никогда не бывает лишней.

Это  коротенько