Short intro: here you can find some info regarding working with My Oracle Support, edition 2018...
Опять участились вопросы по тому, как быть, если SR долго решается, нет ответа со стороны My Oracle Support, и вообще, "-Продукт не работает, Oracle, сделай что-нибудь". Поэтому хочу напомнить (и дополнить) уже публиковавшуюся на easyoraidm инструкцию по тому, как выходить из подобных ситуаций. Подробности - под катом.
Логика корпорации по вопросам поддержки и исправления недостатков продукта примерно следующая.
- все взаимодействие со службой технической поддержки ведется через Service Requests (SR) на My Oracle Support (http://support.oracle.com), SR лучше создавать из-под CSI (Customer Support Identifier) заказчика, в конце концов именно заказчик платит деньги, нет SR = нет проблемы.
- SR может содержать не обязательно проблему, но и вопрос (поддерживается ли что-то и т.д.)
- работа по SR должна приводить к одному из трех результатов: решение проблемы, создание BUG (признанного недостатка продукта в рамках существующего функционала), создание ER (Enhancement Request - желаемые изменения продукта в рамках нового функционала), пока не будет признан BUG или ER, обращаться дальше бессмысленно, разработчики Oracle, которые могут решить проблему, не работают с SR. С точки зрения Development нет бага = нет проблемы.
Дальше - старая, но актуальная инструкция.
1. Если вы столкнулись с проблемой при внедрении - неадекватное поведение продукта, ошибки и т.д., создайте Service Request на My Oracle Support (http://support.oracle.com). Для доступа к функционалу SR'ов вам необходимо зарегистрировать правильный CSI (Customer Support Identifier), лучше чтобы это был CSI заказчика, оплатившего лицензии на продукт.
2. Если вы чувствуете, что работа по SR'у затянулась, эскалируйте SR. О том, как это сделать, описано в статье "How To Escalate a Service Request (SR) with Oracle Support Services [ID 199389.1]". (Update) Продублируйте эскалацию по телефону. +7 495 641 1551 (или по телефонам, указанным для вашей страны). Эскалировать лучше SR с высоким приоритетом (1 и 2).
3. Если вы эскалировали SR по продуктам группы информационной безопасности (IDM, Database Security, Cloud Security), но проблема все равно не решена, нужно добиваться признания бага саппортом. На этом этапе можете попробовать привлечь внимание коллег из нашего офиса (аккаунт менеджера, меня). Мы можем помочь привлечь внимание коллег из саппорта (однако для этого у меня формального процесса нет и мне сложно что-то гарантировать). Чтобы это сделать, мне потребуется информация о заказчике, проекте, объеме сделки и т.д.
4. В случае, если в результате работы по SR'у были созданы BUG или ER, то их также необходимо эскалировать. Номера ER и багов также можете прислать мне с описанием вашего бизнес-кэйза.
5. Большая просьба не присылать мне SR'ы, не имеющие отношения к продуктам ИБ-линейки =)
И по наблюдениям - самые частые проблемы при общении с саппортом.
- меняются инженеры и каждый инженер запрашивает информацию заново - тут ничего не поделаешь, на запросы инженеров поддержки нужно своевременно отвечать, даже если они вам кажутся не касающимися дела
- инженеры поддержки хотят получить доступ к вашей системе, если им не удается воспроизвести поведение, лучше этот доступ предоставить - видео с записью поведения тут работает плохо
- баг/ER создан и заказчик возмущается, почему его не исправляют сразу же - багов и ER много, Dev не может все сделать сразу, необходимо приоритезировать работы, для чего и служат процедуры эскалации. В любом случае не ожидайте, что все будет исправлено на следующий день.
- ER решаются дольше, чем баг - это, к сожалению, нормально. одно дело исправить существующую функциональность, другое - добавить новую.
- пытаются эскалировать SR с приоритетом 3, где со стороны заказчика не было ответа по несколько недель - это работать не будет.
И в заключение. Работа с исправлением недостатков продукта, препятствующих внедрению, требует работы не только со стороны Oracle, но и со стороны заказчика и/или партнера. Эта работа формализована и требует терпения, но в итоге дает свои результаты.
Опять участились вопросы по тому, как быть, если SR долго решается, нет ответа со стороны My Oracle Support, и вообще, "-Продукт не работает, Oracle, сделай что-нибудь". Поэтому хочу напомнить (и дополнить) уже публиковавшуюся на easyoraidm инструкцию по тому, как выходить из подобных ситуаций. Подробности - под катом.
Логика корпорации по вопросам поддержки и исправления недостатков продукта примерно следующая.
- все взаимодействие со службой технической поддержки ведется через Service Requests (SR) на My Oracle Support (http://support.oracle.com), SR лучше создавать из-под CSI (Customer Support Identifier) заказчика, в конце концов именно заказчик платит деньги, нет SR = нет проблемы.
- SR может содержать не обязательно проблему, но и вопрос (поддерживается ли что-то и т.д.)
- работа по SR должна приводить к одному из трех результатов: решение проблемы, создание BUG (признанного недостатка продукта в рамках существующего функционала), создание ER (Enhancement Request - желаемые изменения продукта в рамках нового функционала), пока не будет признан BUG или ER, обращаться дальше бессмысленно, разработчики Oracle, которые могут решить проблему, не работают с SR. С точки зрения Development нет бага = нет проблемы.
Дальше - старая, но актуальная инструкция.
1. Если вы столкнулись с проблемой при внедрении - неадекватное поведение продукта, ошибки и т.д., создайте Service Request на My Oracle Support (http://support.oracle.com). Для доступа к функционалу SR'ов вам необходимо зарегистрировать правильный CSI (Customer Support Identifier), лучше чтобы это был CSI заказчика, оплатившего лицензии на продукт.
2. Если вы чувствуете, что работа по SR'у затянулась, эскалируйте SR. О том, как это сделать, описано в статье "How To Escalate a Service Request (SR) with Oracle Support Services [ID 199389.1]". (Update) Продублируйте эскалацию по телефону. +7 495 641 1551 (или по телефонам, указанным для вашей страны). Эскалировать лучше SR с высоким приоритетом (1 и 2).
3. Если вы эскалировали SR по продуктам группы информационной безопасности (IDM, Database Security, Cloud Security), но проблема все равно не решена, нужно добиваться признания бага саппортом. На этом этапе можете попробовать привлечь внимание коллег из нашего офиса (аккаунт менеджера, меня). Мы можем помочь привлечь внимание коллег из саппорта (однако для этого у меня формального процесса нет и мне сложно что-то гарантировать). Чтобы это сделать, мне потребуется информация о заказчике, проекте, объеме сделки и т.д.
4. В случае, если в результате работы по SR'у были созданы BUG или ER, то их также необходимо эскалировать. Номера ER и багов также можете прислать мне с описанием вашего бизнес-кэйза.
5. Большая просьба не присылать мне SR'ы, не имеющие отношения к продуктам ИБ-линейки =)
И по наблюдениям - самые частые проблемы при общении с саппортом.
- меняются инженеры и каждый инженер запрашивает информацию заново - тут ничего не поделаешь, на запросы инженеров поддержки нужно своевременно отвечать, даже если они вам кажутся не касающимися дела
- инженеры поддержки хотят получить доступ к вашей системе, если им не удается воспроизвести поведение, лучше этот доступ предоставить - видео с записью поведения тут работает плохо
- баг/ER создан и заказчик возмущается, почему его не исправляют сразу же - багов и ER много, Dev не может все сделать сразу, необходимо приоритезировать работы, для чего и служат процедуры эскалации. В любом случае не ожидайте, что все будет исправлено на следующий день.
- ER решаются дольше, чем баг - это, к сожалению, нормально. одно дело исправить существующую функциональность, другое - добавить новую.
- пытаются эскалировать SR с приоритетом 3, где со стороны заказчика не было ответа по несколько недель - это работать не будет.
И в заключение. Работа с исправлением недостатков продукта, препятствующих внедрению, требует работы не только со стороны Oracle, но и со стороны заказчика и/или партнера. Эта работа формализована и требует терпения, но в итоге дает свои результаты.
No comments:
Post a Comment