none
Modelando aplicação de Ordem de Serviço. RRS feed

  • Pergunta

  •  

    Olá a todos,

     

    Estou com uma dúvida sobre como modelar minha aplicação com as seguintes premissas:

     

    Esta é uma aplicação para controlar solicitações de Ordem de Serviço. Nesta aplicação é possível que um usuário solicite serviços de T.I para si mesmo(exemplo: solicitação de acesso a internet), e também solicite para outros funcionários da empresa(exemplo: usuario joaosilva solicita acesso a internet para mariasilva). Podemos ainda permitir ao usuário solicitar serviços para novos empregados(exemplo: criação de login no Active Directory).

     

    Partindo dessa premissa, eu devo modelar meu banco de dados e minha aplicação, que será objeto relacional.

    Pois bem, identifico da premissa acima os seguintes casos de uso:

     

    1. Usuário solicita para sí algum serviço de T.I da empresa.

    2. Usuário solicita para outro usuário algum serviço de T.I. da empresa.

    3. Usuário solicita para um novo usuário(não cadastrado na base) algum serviço de T.I. da empresa.

     

    A solução parcial que eu criei para o banco de dados foi criar as seguintes tabelas:

     

    Tabela Usuario

    id

    login

    nome

    etc....

     

    Tabela OrdemServico

    id - not null

    dataAbertura - not null

    solicitadoPor - not null /* Foreing key para tabela Usuario */

    solicitadoPara null /*Foreing key para tabela Usuario. Caso solicitação feita para si mesmo, este campo tem valor null */

    itensSolicitados

    etc....

     

    Estas duas tabelas contemplam as duas primeiras premissas, onde um usuário pode solicitar serviços para outro usuário, porém aqui surge minha dúvida: como modelar e relacionar as tabelas para que o sistema permita solicitar serviços para usuários não cadastrados? Normalmente o usuário solicitará serviços para um usuário não cadastrado quando este for novo na empresa, então outra pessoal solicita criação de login e criação de acesso a internet para o novo empregado.

     

    Sendo assim eu pensei em uma terceira tabela, porém sem o campo Login, pois ele é novo na empresa, mas não entendo como eu poderei interligá-lo com a tabela de OrdemServico.

     

    Qualquer ajuda ou relato de experiências parecidas é muito bem vindo!

     

    Obrigado a todos e abraços!

    terça-feira, 4 de março de 2008 17:42

Respostas

  • Olá Brandão!!

     

    Muito obrigado pelos seus comentários!

    Inicialmente também tive esta visão, de tratar como uma exceção, para assim reduzir o escopo da ferramenta, mas logo surgiram alguns impecílios.

     

    Um ponto é que a área não tem autonimoa suficiênte para integrar ao RH, temos muitas contratações diárias. Outro ponto é que nem todas as contratações exigem criação de Login na rede.

     

     

    "Ou então o superior do funcionário deve ser que faz o pedido de criação de login"

     

    É exatamente esta a solução "paliativa" que eu encontrei também Brandão. E aí caí neste ponto de modelagem dos dados. No conceito, o supervisor do novo empregado acessa a ferramenta, clica em "Solicitar Nova O.S.". Em seguida, ele checa a opção "Solicitação para outro usuário". Quando ele checa esta opção, um quadro é aberto solicitando as informações do novo usuário. Neste ponto supervisor tem dois caminhos:

    • Solicitação para outro usuário já cadastrado.
    • Solicitação para outro usuário não cadastrado.

    No primeiro caso, o supervisor(ou qualquer outro usuário) informa o Login de rede do outro usuários e os dados são automaticamente preenchidos.

    No segundo caso, o supervisor necessita obrigatoriamente preencher os dados pessoais do novo usuário. Sob minha concepção, estes dados seriam salvos em uma tabela alternativa chamada de ContactException. O problema é como interligá-la com as outras tabelas de usuários.

     

    Um outro ponto ainda é que o supervisor pode ter liberdade de solicitar mais ítens para um novo empregado, além de criação de Login. Ele pode, por exemplo efetuar uma Ordem de Serviço com os seguintes ítens:

    Criação de Login de Rede.

    Criação de conta de email corporativo.

    Liberação de Acesso a Internet.

    Liberação de Acesso ao sistema XYZ.

     

     

    Esqueci de mencionar que todo este "problema" de solicitar para um usuário nao cadastrado acontece pois o sistema de autenticação é feito através do Active Directory, então se o usuário nao tem login, nao pode entrar no sistema e efetuar a solicitação do mesmo.

     

    Deste ponto em diante não sei qual caminho seguir.

     

    Brandão, muito obrigado pela atenção e a ajuda!!!

    quarta-feira, 5 de março de 2008 12:37
  • Fábio,

     

    - Talvez a tarefa de criação do usuário deva ser concluída primeiro para poder fazer as outras.

    - O usuário pode pedir a própria liberação da internet? Acho que esse ponto ou um supervisor deve sempre pedir por um usuário ou deve ter um fluxo de aprovação.

     

    Continuo achando que uma integração com RH seria a melhor opção. Trabalhei em uma grande empresa de informática e sempre na contratação era disparado pelo RH a criação do login de rede, daí entravasse em um fluxo que criava também a caixa de e-mail, acessos a pastas compartilhadas e por aí vai. Talvez você não precise integrar os sistemas, apenas o processo! Tipo criar a parceria com o RH para que na contratação eles abram um chamado pedindo um login para determinada pessoa. Por que eu penso isso: quando você contrata alguém e faz o registro dela na empresa você não precisa do RG, Carteira de Trabalho e etc? Então, sem login o cara não existe, se ele não existe ele não pode abrir chamados!

     

    Se não der mesmo, o negócio é tratar como exceção mesmo, vai ter um campo tarefa e lá o usuário vai pedir um login, no campo descritivo do chamado ele passa os dados, só depois disso é que ele poderia pedir outras coisas, ou então já pedir tudo mas sem saber o login do usuário, porém daí não ficaria um "registro" de solicitação.

     

    quarta-feira, 5 de março de 2008 13:13
  •  

    Meu Caro,

     

    Atualmente trabalho liberando o desenvolvimento de um software desse genero aqui no Chile. Gostaria de lembrar-te o usuario como outro CI (elemento de configuracao de acordo a disciplina ITIL) deve poder ser criado no processo de solicitacao de atencao. Porém, esse usuario, como outro CI qualquer, deve ser homologado por um gerente de configuracao.

    Outras alternativas de integracao ajudam em muito, por exemplo integrar com o ActiveDirectory ou ferramentas como PeopleSoft, porém deve manter o rastro da vida util do elemento de configuracao, assim como seu estado operacional.

     

    Um doble-click no problema mais a fundo te ajudaria a determinar melhor o modelo.

     

    Abs

    -Fernando Costa

    http://sushinetcode.blogdrive.com

    quinta-feira, 6 de março de 2008 18:15
  • Brandao,

     

    Vamos lá: eu disse que no processo de atencao a uma ordem de servico o sistema deve ser capaz de recepcionar a criacao de elementos de configuracao (usuario, equipamento, software, documento...) em linha, mas que que estes devem ser validados por um gerente de configuracao a futuro. Isso nao é algo novo, estou falando de um conjuento de normas criada aos processos de atencao aos servicos de TI ha mais de 18 anos.

     

    Disse que o AD é uma facilidade para integracao com este tipo de sistema (em caso de que o usuario já este criado), pois evita manter os dados do CI em dois ambientes distintos, além disso de replicar as politicas de seguranca de senha num sistema apartado. Me explico? Porém nao é o melhor lugar para gerenciar seu cliclo de vida.

     

    Pela minha experiencia em esse tipo de atividade, somente poucos casos temos o processo de contratacao relacionado com isso. O que nao desvincula a possibilidade da existencia do mesmo. Porem lhe recordo que o processo e a organizacao é mais importante que a ferramenta!

     

    Desculpe se nao o fiz compreender de imediato.

     

    obrigado

    -Fernando

    http://sushinetcode.blogdrive.com

     

     

    quinta-feira, 6 de março de 2008 20:08

Todas as Respostas

  • Fábio,

     

    Sua aplicação ficaria melhor ainda se fosse integrada ao processo de RH da empresa, ou seja sempre que houvesse uma contratação seria disparado a criação do login, e esse poderia ser a primeira Ordem de Serviço.

    Ou então o superior do funcionário deve ser que faz o pedido de criação de login. Repare que você esta tentando resolver uma situação que não será recorrente, por mais que se criem usuários a quantidade de Ordens de Serviço para outras atividades será muito maior; então resolva como uma exceção e não crie uma regra para isso, ou o seu sistema vai inchar cada vez que tornar uma exceção uma regra.

    quarta-feira, 5 de março de 2008 01:13
  • Olá Brandão!!

     

    Muito obrigado pelos seus comentários!

    Inicialmente também tive esta visão, de tratar como uma exceção, para assim reduzir o escopo da ferramenta, mas logo surgiram alguns impecílios.

     

    Um ponto é que a área não tem autonimoa suficiênte para integrar ao RH, temos muitas contratações diárias. Outro ponto é que nem todas as contratações exigem criação de Login na rede.

     

     

    "Ou então o superior do funcionário deve ser que faz o pedido de criação de login"

     

    É exatamente esta a solução "paliativa" que eu encontrei também Brandão. E aí caí neste ponto de modelagem dos dados. No conceito, o supervisor do novo empregado acessa a ferramenta, clica em "Solicitar Nova O.S.". Em seguida, ele checa a opção "Solicitação para outro usuário". Quando ele checa esta opção, um quadro é aberto solicitando as informações do novo usuário. Neste ponto supervisor tem dois caminhos:

    • Solicitação para outro usuário já cadastrado.
    • Solicitação para outro usuário não cadastrado.

    No primeiro caso, o supervisor(ou qualquer outro usuário) informa o Login de rede do outro usuários e os dados são automaticamente preenchidos.

    No segundo caso, o supervisor necessita obrigatoriamente preencher os dados pessoais do novo usuário. Sob minha concepção, estes dados seriam salvos em uma tabela alternativa chamada de ContactException. O problema é como interligá-la com as outras tabelas de usuários.

     

    Um outro ponto ainda é que o supervisor pode ter liberdade de solicitar mais ítens para um novo empregado, além de criação de Login. Ele pode, por exemplo efetuar uma Ordem de Serviço com os seguintes ítens:

    Criação de Login de Rede.

    Criação de conta de email corporativo.

    Liberação de Acesso a Internet.

    Liberação de Acesso ao sistema XYZ.

     

     

    Esqueci de mencionar que todo este "problema" de solicitar para um usuário nao cadastrado acontece pois o sistema de autenticação é feito através do Active Directory, então se o usuário nao tem login, nao pode entrar no sistema e efetuar a solicitação do mesmo.

     

    Deste ponto em diante não sei qual caminho seguir.

     

    Brandão, muito obrigado pela atenção e a ajuda!!!

    quarta-feira, 5 de março de 2008 12:37
  • Fábio,

     

    - Talvez a tarefa de criação do usuário deva ser concluída primeiro para poder fazer as outras.

    - O usuário pode pedir a própria liberação da internet? Acho que esse ponto ou um supervisor deve sempre pedir por um usuário ou deve ter um fluxo de aprovação.

     

    Continuo achando que uma integração com RH seria a melhor opção. Trabalhei em uma grande empresa de informática e sempre na contratação era disparado pelo RH a criação do login de rede, daí entravasse em um fluxo que criava também a caixa de e-mail, acessos a pastas compartilhadas e por aí vai. Talvez você não precise integrar os sistemas, apenas o processo! Tipo criar a parceria com o RH para que na contratação eles abram um chamado pedindo um login para determinada pessoa. Por que eu penso isso: quando você contrata alguém e faz o registro dela na empresa você não precisa do RG, Carteira de Trabalho e etc? Então, sem login o cara não existe, se ele não existe ele não pode abrir chamados!

     

    Se não der mesmo, o negócio é tratar como exceção mesmo, vai ter um campo tarefa e lá o usuário vai pedir um login, no campo descritivo do chamado ele passa os dados, só depois disso é que ele poderia pedir outras coisas, ou então já pedir tudo mas sem saber o login do usuário, porém daí não ficaria um "registro" de solicitação.

     

    quarta-feira, 5 de março de 2008 13:13
  •  

    Meu Caro,

     

    Atualmente trabalho liberando o desenvolvimento de um software desse genero aqui no Chile. Gostaria de lembrar-te o usuario como outro CI (elemento de configuracao de acordo a disciplina ITIL) deve poder ser criado no processo de solicitacao de atencao. Porém, esse usuario, como outro CI qualquer, deve ser homologado por um gerente de configuracao.

    Outras alternativas de integracao ajudam em muito, por exemplo integrar com o ActiveDirectory ou ferramentas como PeopleSoft, porém deve manter o rastro da vida util do elemento de configuracao, assim como seu estado operacional.

     

    Um doble-click no problema mais a fundo te ajudaria a determinar melhor o modelo.

     

    Abs

    -Fernando Costa

    http://sushinetcode.blogdrive.com

    quinta-feira, 6 de março de 2008 18:15
  •  

    Fernando,

     

    Como ele poderia integrar com o AD, se o usuário na existiria no caso de um serviço de criação de login?

    Por isso acho que a saída é disparar o processo de criação na contratação. 

    quinta-feira, 6 de março de 2008 19:08
  • Brandao,

     

    Vamos lá: eu disse que no processo de atencao a uma ordem de servico o sistema deve ser capaz de recepcionar a criacao de elementos de configuracao (usuario, equipamento, software, documento...) em linha, mas que que estes devem ser validados por um gerente de configuracao a futuro. Isso nao é algo novo, estou falando de um conjuento de normas criada aos processos de atencao aos servicos de TI ha mais de 18 anos.

     

    Disse que o AD é uma facilidade para integracao com este tipo de sistema (em caso de que o usuario já este criado), pois evita manter os dados do CI em dois ambientes distintos, além disso de replicar as politicas de seguranca de senha num sistema apartado. Me explico? Porém nao é o melhor lugar para gerenciar seu cliclo de vida.

     

    Pela minha experiencia em esse tipo de atividade, somente poucos casos temos o processo de contratacao relacionado com isso. O que nao desvincula a possibilidade da existencia do mesmo. Porem lhe recordo que o processo e a organizacao é mais importante que a ferramenta!

     

    Desculpe se nao o fiz compreender de imediato.

     

    obrigado

    -Fernando

    http://sushinetcode.blogdrive.com

     

     

    quinta-feira, 6 de março de 2008 20:08
  •  

    Fernando,

     

    Ainda não consegui entender o que você quer dizer com: "...mas que que estes devem ser validados por um gerente de configuracao a futuro."

    quinta-feira, 6 de março de 2008 20:34
  •  

    Olá Fernando!

     

    Obrigado pela sua ajuda !!

     

    Esta minha aplicação é totalmente baseada em ITIL!

    Você possuim algum padrão básico na modelagem de dados para o cenário que mencionei anteriormente?

    Apenas o caminho das pedras já é muito bem vindo! =)

     

    Abraços!!

    segunda-feira, 10 de março de 2008 18:41