3.2 Dashboards actuais do cmNavigo
3.2.3 Overall Equipment Effectiveness (OEE)
Este dashboard possui indicadores de:
• Eficácia da produção (OEE), que pode ser calculado através da multiplicação das percenta- gens das métricas Availability (AVA), Quality (QUA) e Performance (PER).
OEE = AVA × QUA × PER
• Disponibilidade para operar ou uptime (AVA)
• Unidades produzidas com sucesso em relação ao total iniciado (QUA) • Desempenho medido em relação à velocidade projectada (PER)
Solução actual do cmNavigo
Estes indicadores são apresentados, quer para o valor actual nos widgets superiores, quer nos últimos dias, semanas ou meses, indicado nos widgets inferiores.
Figura 3.4: Dashboard OEE no actual cmNavigo.
Para cada um destes dashboards é possível ao utilizador filtrar pelo intervalo de tempo que deseja ver nos gráficos, podendo escolher entre Dias, Semanas ou Meses.
Segundo a CMF a criação destes dashboards foi morosa, pelo que as ferramentas de criação de dashboards resultam também num desenvolvimento mais fácil por parte da CMF. Isto significa que os dashboards pedidos pelos clientes podem ser desenvolvidos e entregues mais rapidamente e potencialmente a uma maior diversificação dos dashboards de base. No entanto, o principal objectivo é tornar o cliente final capaz de desenvolver os seus próprios dashboards.
Capítulo 4
Simplificação do modelo de dados
Uma das características de algumas ferramentas estudadas, incluindo o Syncfusion, é não serem capazes de inquirir o DW através do SSAS. Isto significa que há duas alternativas para inquirir os dados do DW:
• Ou são criadas SPs com interrogações aos cubos recorrendo a MultiDimensional eXpressi- ons (MDX). Este é o método que o cmNavigo utiliza para mostrar os dados presentes nos dashboardsapresentados;
• Ou são consultadas as respectivas tabelas, o que é menos eficiente por não tirar proveito das agregações dos cubos.
Como as SP foram criadas especificamente para as necessidades dos três dashboards mencio- nados, não servem para dashboards com necessidades novas nem permitem explorar os dados.
Ao mesmo tempo, as tabelas possuem muitos dados irrelevantes para o utilizador de BI, úteis para as máquinas, para a gestão do cmNavigo ou na resolução de problemas. Por esse motivo optou-se por criar vistas sobre as tabelas de factos e as suas dimensões, capazes de devolver apenas as colunas que a CMF considera relevantes para o cliente.
Para a criação dessas vistas, contemplaram-se duas abordagens: • Pré-junção
Criar uma vista que devolva a tabela de factos junta (Join) a todas as suas dimensões, sacri- ficando o desempenho a favor da simplicidade do modelo de dados;
• Pós-junção
Criar uma vista para a tabela de factos e outra para cada dimensão. Isto permitirá uma maior personalização da interrogação, juntando apenas as dimensões relevantes, mas obriga a conhecer minimamente o modelo de dados.
A partir desta etapa o estudo passou a recorrer ao servidor e bases de dados de teste da CMF. Para testar as implementações escolheu-se a tabela de factos de materiais (Material).
Simplificação do modelo de dados
Um material pode ser qualquer coisa utilizada no fabrico, desde um chip até à cola usada. A tabela de factos permite rastrear o material ao longo do processo e permite saber quando este foi utilizado, quanto, onde, por quem, com que finalidade, etc.
O modelo de dados dimensional envolvendo a tabela de factos [FactMaterial] e as suas dimen- sões é o seguinte.
Figura 4.1: Modelo de dados dimensional da tabela de factos FactMaterial e suas dimensões.
Conhecendo agora todas as tabelas envolvidas e como estão relacionadas, avançou-se para a escolha das colunas relevantes para os utilizadores em cada uma delas.
Na tabela de factos [FactMaterial] foram seleccionadas as colunas: Seleccionadas nas duas vistas, pré-junção e pós-junção:
[UTCDatetime] - Data em UTC no formato datetime [PrimaryQuantity] - Quantidade de material
[LC1DateTime] - Data na hora local da empresa no formato datetime
Seleccionadas apenas na vista pós-junção, pois necessita das chaves secundárias para posteriormente se juntar às vistas das dimensões:
[MaterialKey], [ParentMaterialKey], [MaterialHierarchyKey], [AreaKey], [StepKey], [Pro- ductKey], [FlowKey], [ResourceKey], [EmployeeKey], [ShiftDateKey], [DateKey], [TimeKey], [ServiceKey], [OperationKey], [RelatedMaterialKey], [MaterialStateKey], [TeamKey], [ShiftKey], [LC1DateKey], [LC1TimeKey], [PrimaryUnitKey], [SecondaryUnitKey]
Na dimensão [DimArea] foram seleccionadas as colunas: Seleccionada nas duas vistas:
Simplificação do modelo de dados
Seleccionadas apenas na vista pós-junção, pois necessita das chaves secundárias para posteriormente se juntar à tabela de factos e à dimensão relacionada, visto que se trata de um esquema em floco de neve (Snowflake):
[AreaKey], [FacilityKey]
Na dimensão [DimDate] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[FullDateAlternateKey] - Data no formato YYYY-MM-DD [DayNameOfWeek] - Dia da semana por extenso (Ex.: Monday) [MonthName] - Mês por extenso (Ex.: October)
[DayNumberOfMonth] - Dia do mês [CalendarYear] - Ano
Seleccionadas apenas na vista pós-junção: [DateKey]
Na dimensão [DimEmployee] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[UserName] - Nome do utilizador (Ex.: “Vasconcelos, Fernando”)
[UserAccount] - Conta do utilizador (Ex.: “CORPORATE\FERNANDO.VASCONCELOS”) Seleccionadas apenas na vista pós-junção:
[EmployeeKey]
Na dimensão [DimFacility] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[FacilityName] - Nome do edifício (Ex.: “Warehouse”) Seleccionadas apenas na vista pós-junção:
[FacilityKey]
Na dimensão [DimFlow] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[FlowName] - Nome do fluxo (Ex.: “DicingBlade”) [Type] - Nome do tipo de fluxo (Ex.: “Production”) Seleccionadas apenas na vista pós-junção: [EmployeeKey]
Na dimensão [DimMaterial] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[MaterialName] - Nome de material (Ex.: “HCB758”)
[Type] - Tipo do material quanto ao destino (Ex.: Se o destino do material é o cliente é “Pro- duction”, se ainda estiver a ser testado é “Engineering”)
Simplificação do modelo de dados
[Form] - Tipo do material quanto à forma como é usado e rastreado no sistema (Ex.: “Consu- mable” ou “Lot”)
Seleccionadas apenas na vista pós-junção: [MaterialKey]
Na dimensão [DimMaterialHierarchy] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[Description] - Descrição da localização do material na sua hierarquia (Ex.: “Inner Material” ou “TopMost Material”)
Seleccionadas apenas na vista pós-junção: [MaterialHierarchyKey]
Na dimensão [DimMaterialState] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[MaterialStateName] - Estado do material (Ex.: “Queued” ou “Dispatched”) Seleccionadas apenas na vista pós-junção:
[MaterialStateKey]
Na dimensão [DimOperation] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[OperationName] - Nome da operação (Ex.: “Assemble”)
[EntityName] - Nome da entidade (Ex.: “Resource” ou “Material”) Seleccionadas apenas na vista pós-junção:
[OperationKey]
Na dimensão [DimProduct] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[ProductName] - Nome do produto (Ex.: “WIRAU0.8HP-MSD”) [Type] - Tipo do produto (Ex.: “Consumable”)
[Description] - Descrição do produto (Ex.: “Gold Wire 0.8 mil HP type (MSD)”) Seleccionadas apenas na vista pós-junção:
[ProductKey]
Na dimensão [DimResource] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[ResourceName] - Nome da máquina (Ex.: “WFS-01.BladeZ1”) [Type] - Tipo da máquina (Ex.: “Consumable”)
[Model] - Modelo da máquina (Ex.: “Feed”)
[Description] - Descrição da máquina (Ex.: “WFS-01.Blade”) Seleccionadas apenas na vista pós-junção:
Simplificação do modelo de dados
[ResourceKey]
Na dimensão [DimService] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[ServiceName] - Nome do serviço (Ex.: “AttachMaterials”)
[ServiceContractName] - Tipo de serviço (Ex.: “MaterialManagement”) Seleccionadas apenas na vista pós-junção:
[ServiceKey]
Na dimensão [DimShift] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[ShiftDefinitionName] - Nome do tipo de turno (Ex.: “8HourShift SMART”) [ShiftDefinitionShiftName] - Nome do turno (Ex.: “ShiftA”)
[StartTime] - Hora de início do turno no formato HH:MM:SS [EndTime] - Hora de fim do turno no formato HH:MM:SS Seleccionadas apenas na vista pós-junção:
[ShiftKey]
Na dimensão [DimStep] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[StepName] - Nome do passo do processo (Ex.: “Mold”) [StepType] - Tipo do passo do processo (Ex.: “Production”) [PrimaryUnits] - Unidades (Ex.: “kg”)
[SecondaryUnits] - Unidade secundária (Ex.: Caso a unidade primária seja “pcs” (pieces) ou “unit”, a unidade a que se refere pode ser “Wafer”)
Seleccionadas apenas na vista pós-junção: [StepKey]
Na dimensão [DimStep] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[Name] - Nome da equipa
[Description] - Descrição da equipa
Seleccionadas apenas na vista pós-junção: [TeamKey]
Na dimensão [DimTime] foram seleccionadas as colunas: Seleccionada nas duas vistas:
[Hour24] - Hora no formato 24 horas (Ex.: 13) [Minute24] - Minuto (Ex.: 12)
Simplificação do modelo de dados
[Second] - Segundo (Ex.: 31)
Seleccionadas apenas na vista pós-junção: [TimeKey]
No caso da pré-junção isto resultou numa só vista, com 62 colunas e 22 tabelas ligadas entre si por inner joins, incluindo chamadas repetidas, como nos casos das tabelas DimTime, DimDate e DimMaterial que são referidas em múltiplas chaves. Devido à enorme quantidade de dados presente, foi adicionado um filtro para somente devolver os dados referentes às últimas quatro semanas (28 dias).
No caso da pós-junção, isto resultou em 22 vistas, com a vista sobre a tabela de factos a ter um filtro igual ao da pré-junção, mostrando apenas os dados das últimas quatro semanas. Como a tabela de factos possui algumas chaves que se ligam à mesma dimensão, como nos casos do DimTime com duas chaves e DimDate e DimMaterial com três chaves cada uma, faria sentido existirem menos de 22 vistas. No entanto, o modo de desenho da fonte de dados do Syncfusion não permite adicionar uma vista mais que uma vez, nem permite estabelecer mais que um join entre as mesmas duas vistas, pelo que se optou por repeti-las com outros nomes. Isto resultou também num benefício, tornou possível dar o mesmo nome da chave da tabela de factos à chave da dimensão, o que resulta num maior acerto na sugestão do join. Isto é relevante pois as vistas não possuem chaves secundárias entre si, logo a sugestão de um join por parte das ferramentas estudadas é feito sobretudo na base do nome e do tipo da coluna.
Concluindo, a diferença entre as duas implementações é notória pela grande diferença entre importar apenas uma vista ou até 22, o que também implica verificar a correcção das junções e saber quais as dimensões necessárias. Pela facilidade de uso, a pré-junção parece a estratégia mais adequada, permintindo ao utilizador explorar, sem conhecer o modelo de dados.
Capítulo 5
Teste da solução proposta
O desenvolvimento dos dashboards presentes no cmNavigo foi moroso, pelo que era impor- tante saber se era possível criá-los de forma mais fácil através do Syncfusion.
5.1
Replicação dos dashboards do cmNavigo
Não podendo aceder por SSAS através do Syncfusion, é possível fazê-lo através do MSSQL, recolhendo os dados necessários do DW através de SP com chamadas de selecção em MDX para os cubos. Essas SP estão na base de dados ODS.
• P_GetReasonsFrequencyAndPercentage_ODS
Utilizada para obter os problemas mais frequentes na produção, juntamente com a sua frequência e percentagem do total de problemas existentes, que são representados no gráfico da direita no dashboard PKPI;
• P_GetResourceOEE_ODS
Utilizada para obter os dados no dashboard OEE. Os valores do OEE, Availability, Quality e Performance presentes em cima são os actuais, enquanto que os do gráfico em baixo são dos últimos sete dias, semanas ou meses;
• P_GetResourcePerformance_ODS
Utilizada para obter o Uptime, Downtime, MTBF e MTTR dos gráficos de cima no dashbo- ardRKPI. Os valores por baixo do título são o valor actual, enquanto que os dos gráficos mostram os dos últimos sete dias, semanas ou meses;
• P_GetResourcePerformanceStateChange_ODS
Utilizada para obter os estados de cada máquina (Resource) ao longo do tempo, para ser mostrado no cronograma no canto inferior direito do dashboard RKPI;
Teste da solução proposta
• P_GetResourcePerformanceStateChangeSummary_ODS
Utilizada para obter o tempo total que as máquinas (Resources) estiveram em cada estado, para ser mostrado no gráfico de barras no canto inferior esquerdo do dashboard RKPI;
• P_GetYieldAndCycleTime_ODS
Utilizada para obter o Yield e Cycle Time presentes nos gráficos da esquerda do dashboard PKPI. Os valores por baixo do título são o valor actual, enquanto que os do gráficos mostram os dos últimos sete dias, semanas ou meses.
As mesmas Stored Procedures foram utilizadas para replicar os dashboards no Syncfusion. O Syncfusion não possui um widget que pudesse representar o cronograma de forma seme- lhante, pelo que este foi deixado de fora. E como o Syncfusion possui uma grelha e pouco espaço para colocar widgets, alguns foram colocados no seu espaço.
Teste da solução proposta
Figura 5.2: Dashboard PKPI replicado no Syncfusion.
Figura 5.3: Dashboard OEE replicado no Syncfusion.
Como o Power BI afirma ter a intenção de, no futuro, permitir a publicação de dashboards on-premisespara o SSRS também se desenvolveram os dashboards nesta ferramenta.
O Power BI não possui de origem um widget que pudesse representar de forma semelhante o cronograma e não se encontrou uma solução simples no mercado da ferramenta, pelo que este foi descartado. Como no Power BI é mais versátil na escolha do espaço e dimensionamento dos widgets, manteve-se a mesma disposição.
Teste da solução proposta
Figura 5.4: Dashboard RKPI replicado no Power BI.
Teste da solução proposta
Figura 5.6: Dashboard OEE replicado no Power BI.
Por fim, e porque a CMF tem clientes que possuem o Tableau, resolveu-se desenvolver so- mente o dashboard RKPI. Isto permite ter uma ideia de como seriam os dashboard no Tableau e como podem ser servidos os clientes que já possuem essa solução de BI.
Teste da solução proposta
Como o Tableau possui um widget de cronograma, o mesmo foi adicionado. Neste é possível ver o detalhe de cada estado, com o nome da máquina (“BOV-03”), o estado (“Standby”) e a data de início e de fim desse estado.