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

П.5 эскалируем - у меня есть опыт когда результат эскалации пришел спустя... эн месяцев после начала проекта, но там соскочить было не вариант :)
А теперь картина - 17 систем с одним (!) доступом через проприетарную защиту, которая рубит при попытке коннекта вторым окном все 😂

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

у меня хуже было... 10 человек команда - 2 учетки.  Эскалация важна тем, чтобы когда будут разбирать косяки  не сказали "а чо ты сидел и молчал"

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

Елена, я описываю реальный  case. Предшественник был persona non grata. Не для меня. Для гендира. Какой там консультант...

Мда... печально. Жизнь есть жизнь.

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

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

Елена, очень хорошо, правда, но немного почелленджу ваш богатый опыт.
1. Что конкретно считать подводными камнями? SLA можно считать приемлемым, если есть параметры сервиса и он оказывается в соответствии с ожиданиями заказчика. В рамках дью дилидженс такая оценка не корректная, поэтому нужно конкретизировать, что мы будем считать плохим SLA.
2. Наличие процессных документов это индикатор уровня зрелости. Очень старые документы могут говорить о том, что процесс стабилен и не требует тюнинга. Критерии, что считать документом написанным "на отъебись" нет, т.е. оценка качества сутевой части опирается только на уровень профессионализма в предметной области оценивающего. Есть чек-лист для вычисления такой оценки, он был бы уместным мерилом.
3. История тикетов - тут согласен без поправок
4. Проверка инфраструктуры это часть проверки SLA. Внутри есть оценка Underpinning contact, где все это проводится наблюдательной комиссией. Сейчас качество таких документов определяющих взаимодействие намного выше, чем лет 10 назад и +/- все научились друг у друга копировать сутевую часть. Вот проверка отражения как организовано взаимодействие людей в контрактах корректное замечание. Матрицу ответственности при проблемных контрактах вы умотаетесь согласовывать, если подрядчика кидали и ему не платили денег. На этапе транзишена такая опция спорная, надо внимательно следить за динамикой отношений. Бэкапы - ок, maintenance - ok. Доступы - не Ок. Их могут просто не дать, т.к. для оказываемого сервиса вы никто. И для дью дилидженс тоже. Работает безопасность могут тупо запретить. в это плоскости надо работать через менеджмент подразделений, это их ЗО в рамках передачи управления Вот матрицу ролей  надо челленджить и проверять процесс выдачи доступов, инвентаризировать список всех учеток и сверять по журналам кем и когда вносили последние измения - это да.
5- проверка кода - ок.
6- гораздо хуже, если у заказчика нет планов или они не понимают, какой сервис они купили или что им положено в рамках его приобретения. Наличие масштабных планов это скорее всего индикатор того, что текущий сервис говно, они хотят его свапнуть на другой и рефакторинг дороже перезапуска. Если были проекты презентаций, где делали ПФА (план-факт анализ), SWOT анализ и проекты решений - дело вязнет. Потому что рестарт услуги в таких случаях часто происходит без детальной оценки деятельности по предыдущим пунктам, а вам как менеджеру по транзишену именно это в рамках дью дилидженс и нужно показать, точное состояние As is.

Коллеги,  спасибо! Действительно хорошие комментарии. И я вам при этом честно завидую. Потому что мне довелось быть менеджером перехода со сроком "внезапно и немедленно", "нам нужно без объявления войны сменить предыдущего аутсорсера". Опыта я наелся уже немерянно ) Но из вашего "идеального" сценария реально есть чего почерпнуть.

1. SLA
1. смотрим что он впринципе считается
2. SLА из контрактов совподает с SLA в процессных документах
3. Все ( исполнители, потребители услуги, заказчики услуги) знают о данном SLA
4.  Мы  технически и физически можем оказывать услугу  согласно тому, что написано в контракте

2. Документы
Есть документы просто без которых сложно жить. Это как в армии:  невозможно жить без устава.
Если нет Process menegment - пишем сами.  Просто описываем как есть.  Простой кейс -  пришел новый человек в команду, вот как ему без документа  объяснить тот же ticket routing, а если пришло  2-3 человека, то замучаешься устным народным творчеством заниматься.

3. Смотрите, по поводу документов на  сервисе: у многих есть двойное назначение. Та же матрица использовалась командой  при P1 Инцидентах.  Мы  открывали сей документ и быстро собирали нужным ответственных  для ускорения решения инцидента.

На отьебись-   это  контент документа не проверяем, документ неряшливо оформлен, в документе сложно разобраться  специалисту,  много информации, но ей никак не воспользуешься(описано как поток мыслей, нет структуры и тд).


4.  Если доступы не дают -  эсколация +  предупреждение о соотвествующих рисках.
Да, я к своем стыду забыла упомянуть риск матрицу :(

Больше добавить нечего:) Спасибо Вам, что все так круто разложили)

Коллеги,  спасибо! Действительно хорошие комментарии. И я вам при этом честно завидую. Потому что мне довелось быть менеджером перехода со сроком "внезапно и немедленно", "нам нужно без объявления войны сменить предыдущего аутсорсера". Опыта я наелся уже немерянно ) Но из вашего "идеального" сценария реально есть чего почерпнуть.

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