3.4.1. Benchmarking
Por benchmarking, entenda-se o processo contínuo e sistemático que permite a comparação das performances das organizações e respectivas funções ou processos face ao que é considerado "o melhor nível", visando não apenas a equiparação dos níveis de performance, mas também a sua ultrapassagem (Instituto de Apoio às Pequenas e Médias Empresas e à Inovação 1996).
Na sequência desta actividade, foi realizado algum benchmarking como suporte à concepção de modelos conceituais. Neste sentido, pretendeu-se analisar o posicionamento dos serviços e dos recursos de informação de outras bibliotecas universitárias.
3.4.2. Diagramas do Service Experience Blueprint (SEB)
A representação gráfica da aplicação do SEB implica o uso de uma notação própria, que embebe dos elementos do Service Blueprinting e de diagramas de actividade da UML, tal como se pode constatar na tabela seguinte:
Tabela 3: Notações do Método SEB – (adaptado para português de Patrício, Fisk, Cunha 2008-a)
Uma actividade é uma acção realizada por um participante no processo de execução do serviço.
A seta de transição une as actividades dos diferentes actores, definindo assim o fluxo de eventos.
___________________________________________________________________________________________________________________________________________________________________________________________________ - 55 -
Swimlane A swimlane mapeia as actividades que são da
responsabilidade de um actor ao longo de todo o serviço. A linha de interacção separa as actividades dos diferentes actores ao longo do serviço.
A linha de visibilidade separa, dentro das actividades de um actor mapeadas numa swimlane, as que são visíveis e as que não são visíveis.
FRONTSTAGE O frontstage contém as actividades que são visíveis para
o cliente.
BACKSTAGE O backstage contém as actividades que suportam o
serviço e não são visíveis para o cliente (utilizador). O início do processo representa o ponto onde a execução do serviço em causa começa.
O fim do processo representa o ponto onde a execução do serviço em causa termina.
A ligação da interface do serviço indica que o processo de prestação do serviço se transfere de uma interface do serviço para outra, com a indicação da entidade de onde vem ou para onde vai.
Pontos de espera representam pontos no processo onde
um atraso poderá ocorrer.
Pontos de falha representam pontos no processo onde
poderá ocorrer uma falha, com um impacto negativo para a experiência do utilizador.
De acordo com este método, as actividades são as acções em que se encontra dividido o serviço. Estas são despoletadas por algum participante, no processo de execução do serviço, e estão ligadas entre si através de setas de transição. Deste modo, as actividades representadas na swimlane de determinado actor são da sua responsabilidade. Deve-se colocar um ponto de início para representar o momento em que as actividades de um determinado processo foram iniciadas. Por sua vez, quando as actividades de um serviço terminam deve aparecer um ponto de fim do processo. Quando a execução do serviço não encerra na interface representada, deve aparecer uma “ligação da interface do serviço”, referindo a interface em que o processo continuará a decorrer.
As linhas de interacção circunscrevem as swimlanes, definindo quais as actividades que são da responsabilidade de cada actor. As linhas de visibilidade operam como uma
___________________________________________________________________________________________________________________________________________________________________________________________________ - 56 -
barreira, limitando o que é visível para cada actor. No frontstage são representadas as actividades que são visíveis sob o ponto de vista do utilizador, sendo que no seu inverso, no backstage, são apresentadas as actividades relevantes para o serviço, tornando-se invisíveis para o utilizador.
De referir ainda, os pontos de falha que permitem sinalizar os momentos em que podem ocorrer essas falhas, com reflexos negativos para a experiência do utilizador e os pontos de espera, que se traduzem na possibilidade da ocorrência de atrasos em determinados momentos.
No capítulo seguinte é possível conferir alguns destes diagramas, que ilustram as propostas de redesenho dos serviços, a partir dos quais foram desenhadas as interfaces que compõem o protótipo semi-funcional do novo website do SDI.
3.4.3. UML
Em 1994, teve origem a Unified Modelling Language (UML), tendo como objectivo central agregar três técnicas de modelação, orientadas a objectos, para se assumir como a linguagem unificada neste âmbito (Braun 2000). Neste momento, a versão mais recente é a 2.2, disponibilizada em Fevereiro de 2009 (Object Management Group 2009). A entidade que está responsável pela criação e manutenção da UML é o Object Management Group (OMG), a qual define a UML como sendo uma linguagem gráfica para visualizar, especificar, construir e documentar requisitos de sistemas de software.
De acordo com o Object Management Group/Business Process Management Initiative (2006), ao recorrer-se a uma abordagem baseada em objectos e sem compromissos com nenhuma tecnologia, a UML permite que pessoas procedentes de diferentes áreas possam trabalhar em conjunto sobre o mesmo modelo.
Segundo o Object Management Group (2009), actualmente a UML inclui treze tipos de diagramas, que podem ser compartimentados em três secções, os quais se apresentam abaixo:
Diagramas de estruturas: Class Diagram, Object Diagram, Component Diagram,
Composite Structure Diagram, Package Diagram e Deployment Diagram.
Diagramas de comportamentos: Use Case Diagram, Activity Diagram e State
Machine Diagram.
Diagramas de interacção: Sequence Diagram, Communication Diagram, Timing
___________________________________________________________________________________________________________________________________________________________________________________________________ - 57 -
Este leque de diagramas permite analisar os requisitos da aplicação que se está a projectar e desenhar uma solução que satisfaça as partes envolvidas no processo. Além de permitir a captura de informação sobre software orientado a objectos, esta linguagem também facilita a obtenção de informação sobre a actividade de negócio.
Ao utilizar-se esta notação gráfica normalizada, qualquer modelo construído com a UML pode ser interpretado sem ambiguidades.
___________________________________________________________________________________________________________________________________________________________________________________________________ - 58 -
___________________________________________________________________________________________________________________________________________________________________________________________________ - 59 -