Práticas de Negócios Back Office Brasil. AGENDAck Office Brazil Objetivo Back Office x Contracts Funções e Responsabilidades Processando pedidos de compra.

Apresentação em tema: "Práticas de Negócios Back Office Brasil. AGENDAck Office Brazil Objetivo Back Office x Contracts Funções e Responsabilidades Processando pedidos de compra."— Transcrição da apresentação:

1 Práticas de Negócios Back Office Brasil

2 AGENDAck Office Brazil Objetivo Back Office x Contracts Funções e Responsabilidades Processando pedidos de compra Ferramentas e Templates Práticas de Negócio - checklist Booking Pós-booking

3 Back Office Brasil Time – Ana Tavares (Ana.Tavares@oracle.com) Manager / Lad Sales Orders / DPO – Daniela Bannitz (Daniela.Bannitz@oracle.com) VADs / Partners/ Cliente região BR ( exceto SP e Sul) – Mariana Lima (Mariana.Rosanti.Lima@oracle.com) VAD /Partners / Regiões SP e Sul

4 Back Office x Contracts BACK OFFICECONTRACTS Validar e bookar : Ordens indiretas "Standard"Validar e bookar : Ordens Diretas e Indiretas não "Standard" Produtos de Tecnologia e AplicativosLOCAL - CADMIN Pedido online : POP (Partner Ordering Portal)ULAs Apoiar Parceiros e VadsEnterprise Linux e VM Suporte pré e pós vendas Orientação no preenchimento de Bap Form – Apps eCOSTA RICA Enterprise Linux e VMMigrações : Como utilizar a Ferramenta POPCliente Privado Dúvidas sobre práticas de negócioCliente Setor Público Backlog : Faturamento, previsão de entrega da mídia

5 Preparando um pedido de compra Tipos de pedidos : 1.Pedido “Standard” – Pedidos onde os termos contratuais da Oracle são aceitos sem nenhuma solicitação de alteração do cliente. A internalização deve ser através de Bap Form ou POP (Online). 2.Pedido não “Standard” – Qualquer ajuste solicitado pelo cliente, que seja necessário alterar as cláusulas padrões da Oracle : Pedido com aquisição maior que 12 meses de suporte; Pedido com parcelamento de Suporte; Migrações; Hosting Genérico ou Específico; – Lembrete : Ao assinar o PDF, sempre preencher o campo : “Contrato de Licença do usuário final” com o número interno do seu pedido.

6 Preparando um pedido de compra Pedido “Standard” : Produto Apps Cliente Privado – Vad/Partner deve preencher o BAP Form e POEU com a versão mais atualizada. Cliente Setor Público – Vad/Partner deve preencher o BAP Form modelo específico para Setor Público com a versão mais atualizada e enviar draft dos documentos que deverão ser assinados. Documentos exigidos para pedido Setor Público Processo licitatório do próprio orgão : – Edital e Anexos; Processo licitatório com registro de preço, a aquisição do orgão detetor da Ata ou do Orgão Previsto no Edital: – Ata de Registro, Edital do Registro e seus anexos; Processo licitatório, adesão a Ata de Registro de Preços de Orgão distinto : – Ata de registro, Edital do registo e anexos, oficio para adesão de solicitação e autorização – Registro no Diário Oficial da União; Proposta Padrão Oracle com cláusula OLSA

7 Preparando um pedido de compra Pedido para Enterprise Linux e VM Cliente Privado e Setor Público – Vad/Partner deve preencher o BAP Form com a versão mais atualizada. ELSA – Documento assinado entre Oracle e cliente final, e o Vad ou o parceiro que está intemediando a venda, é responsável por encaminhar o ELSA para o cliente final assinar.  Após o preenchimento : – Vad/Partner encaminha ao time de Back Office a documentação preenchida para validação, através dos e-mails citados anteriormente; – BackOffice responde ao Vad/Partner, apontando as correções necessárias. Back Office não valida o Bap Form e POEU separadamente.

8 Ferramentas e Templates Para registro de OPP : – PRM Para preparar pedidos “standard” e não “standard”: – Legal Name Change – solicite ao Sales Rep – Carta de exceção : - solicite ao Sales Rep  Pedidos com desconto adicional  Pedidos com prazo diferenciado de Suporte  Pedidos com prazo de pagamento diferenciado de Suporte Para preparar pedidos “standard” para pedido de Apps : – Bap Form : Cliente Privado e Setor Público (Bap Form modelos distintos) – POEU (Proof of end user) – Proposta padrão Oracle com cláusula do OLSA : somente para Setor Público Para preparar pedidos de Enterprise Linux e VM: – Bap Form : Cliente Privado e ou Setor Público (Mesmo Bap Form) – ELSA : Assinado pelo cliente final

9 Pedido indiretos “standard” Quais as regras? – Pedidos acima de USD 200K net licença é obrigatório encaminhar POEU ou Contrato assinado entre parceiro e cliente final Como é processado? 1.A documentação deverá ser enviada para Back Office, estar legível, com as devidas assinaturas identificadas com o nome completo e cargo, para cliente final e parceiro. 2.Todas as documentações solicitadas na validação, já devem estar concluídas e submetidas ao Backoffice. 3.Não é necessário neste momento, o pedido original para booking, poderá ser enviado por Fax, digitalizado por e-mail, desde que legível. 4.Posteriormente, para efeito de auditoria, o pedido original deverá ser encaminhado ao Back Office para assinatura da Oracle, e arquivamento. 5.Caso o VAD precise de uma via para seu controle, deverá ser enviado o pedido original em duas vias para a Oracle. Importante : – Pedidos com desconto adicional, deve ser previamente aprovados pelo vendedor Oracle;

10 Práticas de Negócio - Checklist Pedido acima de USD 250k (valor lista Lic + Sup) o desconto e-biz do parceiro/Vad aumenta em 5%. VAD vendendo direto para Cliente final, a Oracle precisa solicitar aprovação interna ; Todo parceiro tem um VAD preferencial, caso o parceiro utilize outro VAD para fazer uma compra será necessário obter as aprovações: do VAD liberando o seu parceiro para fazer esta venda, e da Diretoria de Alianças Oracle. O parceiro que estiver intermediando a venda do VAD, deve possuir o FUDA Light vigente com a Oracle. Não serão aceitos pedidos internalizados na Oracle com assinatura anterior ao mês corrente, na virada do quarter.

11 Pós Booking Cliente recebe: – Notificação do CSI, via e-mail, através da Welcome Letter. – Esta notificação sempre será enviado para o endereço de e-mail informado no pedido de compra, pelo Vad/partner, portanto sempre verificar se o e-mail está correto antes de submeter o pedido para booking.