Por Techopedia Staff, 8 de novembro de 2017
Resumo: O anfitrião Eric Kavanagh discute a maturidade dos dados e a maturidade organizacional com Jen Underwood, do Impact Analytix, e Ron Huizenga, do IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Tudo bem, senhoras e senhores. Olá e bem-vindo de volta mais uma vez. É quarta-feira, às 4 horas, no leste, o que significa que é hora das Tecnologias Quentes. Sim, de fato. Meu nome é Eric Kavanagh; Serei seu anfitrião do nosso programa de hoje, que realmente está definido, projetado para definir certos tipos de tecnologia em certos estados do mundo do gerenciamento de dados. E o nosso tópico hoje é "Alcançando a maturidade dos dados: um ato de equilíbrio organizacional". Portanto, esse é o seu ponto de vista, entre em contato comigo no Twitter, @eric_kavanagh. Eu sempre retuito, se você me mencionar, e tentarei segui-lo também. É um bom lugar para obter informações sobre o que está acontecendo no mundo. Eu amo esse formato. Caracteres curtos, 140 caracteres - ou mais atualmente. Portanto, sinta-se à vontade para me enviar um tweet e eu voltarei a segui-lo.
Este ano é quente, é claro. Hoje estamos falando de maturidade de dados e aqui está a programação, com a sua verdadeiramente no topo. Temos um novo analista hoje; Estou muito animado por ter Jen Underwood, do Impact Analytix. Ela é especialista em inteligência de negócios, análise e visualização de dados e em todos esses ótimos tópicos. E, claro, maturidade dos dados. E nosso amigo Ron Huizenga está ligando do IDERA. Então, primeiro vamos ouvir Jen e depois Ron. E então teremos uma boa discussão em mesa redonda.
Enquanto eu empurro este próximo slide aqui, vou apenas dizer algumas palavras rápidas. A maturidade do gerenciamento de dados já é assunto há algum tempo. Obviamente, na história, você precisa chegar a um certo ponto antes de começar a pensar em maturidade, e muitos ciclos de vida de maturidade foram desenvolvidos - ou ciclos - tentando descobrir onde você está na curva. Você é um estágio inicial? Você é adolescente? Você é maduro? Etcetera.
E acho que muitas organizações estão na adolescência ou no final da adolescência ou no início dos anos vinte em termos de maturidade. E isso não está dizendo nada desanimador. Só que ainda estamos nos primeiros dias em que conseguimos gerenciar dados como um ativo estratégico. E as coisas estão mudando rapidamente. Especialmente nos últimos cinco a sete anos, à medida que mudamos de pequenos dados para grandes dados e eles estão tentando conciliar esses mundos e novas tecnologias bastante díspares com as tecnologias antigas. Então, o legado está lá fora, está em todo lugar.
Uma das piadas que ouvi anos atrás é que o legado é um sistema em produção. No momento em que um sistema entra em produção, tecnicamente é legado. E de uma maneira que é verdade. Mas o ponto principal é que temos todos esses sistemas que existem há muito tempo e precisamos encontrar uma maneira de entender onde estamos em nossa própria curva de maturidade para poder maximizar e otimizar o valor dos dados como um ativo. . E, é claro, existem alguns problemas de conformidade, alguns regulamentos com os quais precisamos nos preocupar, dependendo do setor em que estamos. E é claro que também precisamos nos preocupar com hackers. No passado, falamos sobre governança de dados e como isso é realmente parte integrante da segurança e apenas para entender as funções e responsabilidades do uso de dados e garantir que possamos obter o melhor valor possível.
E assim, vou entregar as chaves a Jen Underwood e ela pode nos dizer sua perspectiva sobre a maturidade dos dados. Jen, leve embora.
Jen Underwood: Obrigado, Eric, e obrigado por me convidar. Hoje, vou abordar alguns tópicos diferentes e apresentar o Ron com o IDERA, e ele vai se aprofundar em outras áreas desse tópico em particular. Eu direi que é um papel crítico na era digital ou na transformação digital em que estamos agora e, como Eric havia dito, é uma era em evolução. Algumas estatísticas divertidas do Conselho EDM, houve um relatório de benchmark do setor de gerenciamento de dados. Ele tem quase dois anos de idade, mas ainda é bastante relevante e revelará alguns dos factóides, por si só, de ser um adolescente neste espaço. Vou falar um pouco sobre a maturidade dos dados e os pilares da governança, por si só.
Sobre esse tema da era digital ou da transformação digital que você está ouvindo em todos os lugares, isso está realmente acontecendo agora. Um dos fatos interessantes que reuni ao seguir o setor todos os dias foi um argumento do Gartner em suas dez principais tendências de tecnologia estratégica. E eles disseram em 2020 - então estamos a apenas alguns anos disso - as informações serão usadas para reinventar, digitalizar e automatizar ou eliminar 80% dos processos que temos da década anterior.
E eu vejo isso há algum tempo, acho que aqui você está vendo diferentes tipos de pessoas dizendo, você sabe, "Os dados são o novo petróleo", e esses tipos de coisas. Eu gosto de dizer que agora os dados são ouro digital. E se você pensar em aplicativos de software e envolvimento de software, eu era gerente mundial de produtos da Microsoft no passado e até mesmo a mudança na minha carreira de, sabe, nos concentraríamos realmente no software, agora focados nos usuários e reunindo os dados e pensando em monetização dos dados.
Estamos entrando nessa era em que os dados são ouro digital e você começa a perceber que, com o surgimento do que é chamado de diretor de dados, eles são, você sabe, duas missões principais - e certamente algumas outras - de garantir que os dados estejam seguros e também de encontrar maneiras de maximizar o valor dos dados internamente - e até externamente - como esse ativo digital. Portanto, esses tipos de coisas que podem não ter sido, ou podem não ter parecido importantes para sua organização no passado, finalmente os dados estão ocupando um lugar na tabela de nível C com o CDO e serão levados muito mais a sério daqui para frente.
Se você pensa em gerenciamento de dados e maturidade, há dois temas diferentes que tenho neste slide em particular aqui, o primeiro sendo, você sabe, o próprio gerenciamento de dados. É mais sobre as funções de negócios que desenvolvem e criam dados e fluxos de dados, algumas das políticas e práticas existentes. E então, quando você pensa sobre a maturidade do gerenciamento de dados, é a capacidade de uma organização de definir com precisão, integrar facilmente, você sabe, aproveitar esses dados que eles têm novamente para fins internos ou externos, como monetização de dados. E um dos grandes temas - e tem sido engraçado, no início da minha carreira, e eu realmente aproveitei alguns dos projetos de ferramentas e arquitetura de dados do IDERA - era todo esse conceito de metadados e continuamos pensando nos metadados, e depois não foi discutido por muito, muito tempo. Finalmente estou vendo que os metadados são legais novamente. É realmente muito importante interagir com diferentes grupos, entender onde estão seus dados e quais são. Especialmente em coisas como um lago de dados. Está finalmente, finalmente ficando interessante.
Agora, prometi ter aqui algumas estatísticas de um relatório de benchmark do setor. Este foi de 2015 para o Conselho EDM. Trata-se de modernizar a qualidade e a governança dos dados, e há alguns fatos divertidos nesse particular. Portanto, aqui, mais de 33% das organizações têm um programa de gerenciamento de dados ativo e formal em algum nível da organização - apenas 33. Isso é muito interessante por si só. Dos 50% que realmente formalizaram, queremos gerenciar dados, percebemos que esse é um ativo realmente importante em nossa organização, assim como os humanos têm recursos humanos. Apenas 50% deles tinham programas com mais de um ano. Portanto, novamente, essa é uma área emergente, é realmente muito interessante no que nos tornamos cada vez mais importantes, especialmente com coisas como alguns dos regulamentos da indústria saindo.
Então, nesse ponto, muitas vezes - e é interessante ter atuado em vendas e funções técnicas ao longo da minha carreira - não era realmente: “Oh, podemos economizar dinheiro que motivaria uma organização” - geralmente é medo. É mais, “Oh meu Deus, precisamos ter certeza de que estamos cobertos. Não queremos perder nossos empregos. ”E certamente coisas como riscos de hackers e dados e vazamento de dados, há estudos de benchmark realmente interessantes sobre isso. A Verizon faz uma a cada ano e é provavelmente uma das minhas favoritas para revisar. O que você quase sempre vê é inadvertido, não é necessariamente, você sabe, mau uso intencional dos dados ou má gestão dos dados que resulta em um vazamento. E frequentemente - eles não têm essas estatísticas para esta sessão em particular -, mas é fascinante que esses vazamentos acidentais de má administração de permissões e etc. Você sabe, para facilitar um pouco as coisas, esses vazamentos são emprestados. E geralmente para pessoas que são secundárias ou externas à sua organização, e não é isso que você deseja.
Portanto, esses são os tipos de coisas em que você pensa em ter um programa de segurança e governança de gerenciamento de dados. Você sabe, não apenas decisões ruins e economia de dinheiro, mas também garantir que você esteja seguro, que esteja cumprindo as legislações de privacidade e segurança. Você é capaz de monetizar dados nesta era digital e, é claro, você quer fazer as coisas com eficiência, reutilizar dados e ter a cópia abençoada e ter - eu odeio quando as pessoas dizem, e eu estou na análise e eu. há muito tempo analítica, uma versão da verdade. Geralmente, você sabe, geralmente existem várias versões da verdade, apenas de diferentes perspectivas. Mas, essencialmente, você deseja que os dados sejam confiáveis nos quais você baseia as decisões.
Um dos maiores drivers que eu estou vendo - e é bom, é bom que esteja esfriando de novo - é todo o conceito do RGPD da União Europeia. E deixe-me falar um pouco sobre isso. Portanto, se você não conhece o GDPR, ouvirá muito sobre isso no próximo ano. É uma nova legislação que está ocorrendo em maio. Ele será aplicado em maio de 2018 e possui algumas grandes penalidades pela má gestão das informações. Talvez você já tenha ouvido falar sobre isso de outras formas - talvez não esteja usando o termo GDPR - ou talvez tenha visto isso escrito como o direito a ser esquecido, o que significa que você pode entrar em contato e pedir aos fornecedores que removam seus dados. Novamente, arquitetos de dados antigos, eles não removeriam dados. Nós alterávamos, tornávamos inativos em cenários de data warehousing. Nós realmente nunca excluímos nossos dados. Não tínhamos processos para isso. Portanto, são coisas que afetarão todos os aspectos da sua organização e diferentes maneiras e processos que você nunca pensou em construir seu aplicativo ou data warehouse. Portanto, se você pensar em algo sobre o GDPR, logo precisará de uma base legal para justificar a coleta e o processamento de dados pessoais.
Portanto, isso é principalmente no nível pessoal, portanto, o consentimento precisa ser dado livremente: específico, informado e inequívoco. E isso afetará muitas áreas da inteligência artificial e da ciência de dados - essa é a área que abordo hoje em dia são as implicações da ciência de dados e apenas para garantir que haja alguma transparência nos modelos - além de muitas outras áreas do seu autoatendimento BI, seu data warehouse, seu gerenciamento de dados mestre e até mesmo projetos de seus clientes 360, para personalização e até seus aplicativos de linha de negócios. Então isso é algo que vai tocar todas as partes da sua organização. E, diferentemente das leis de privacidade de outras jurisdições, o GDPR será aplicável a qualquer organização localizada dentro ou fora da União Europeia. E as multas de conformidade, novamente, são significativas. A sua organização pode ser multada em até quatro por cento do seu total bruto anual - acredito que seja chamado de rotatividade - renda per se.
Espero ter sua atenção e essas são coisas que você deve prestar atenção. Se sua empresa já segue algumas dessas práticas e padrões do setor com o PCI, talvez seja uma ISO - não tenho certeza se vou dizer isso corretamente - 27001. Se você já está realizando algumas delas, não deve ' Não seja muito avassalador, mas certamente é algo para estar ciente. Assim, enquanto você se prepara para isso, há algumas áreas, especialmente no gerenciamento de dados, e uma das primeiras coisas é ter um catálogo e classificar seus dados - sabendo onde seus dados estão localizados. E em um mundo, um mundo híbrido, onde os dados vivem em todos os lugares: estão na nuvem; está nesses aplicativos; está na força de vendas; é em algum outro programa aleatório que o marketing também está usando, você sabe, seus sistemas de clientes ou seus sistemas de inventário - todos esses tipos de lugares. Saiba onde estão seus dados e a coisa mais fácil de fazer - e essa tem sido uma área realmente divertida de gerenciamento de dados. São esses conceitos desses catálogos de dados que têm inteligência, até a classificação de aprendizado de máquina é algumas das informações.
E, novamente, metadados - mencionei que os metadados estão ficando legais de novo, então, pensando realmente em metadados e não encobrindo esse tópico importante quando você começa a projetar lagos de dados e esses tipos de coisas, e, é claro, governando e monitorando esses. Portanto, o monitoramento se tornará muito mais importante quando você precisar voltar e alguém do GDPR, por exemplo, poderá solicitar que você prove para onde foram esses dados, quem os possui, quem teve acesso, etc. Porque você realmente terá que mostrar às autoridades esse tipo de coisa.
Para ajudá-lo com a maturidade do gerenciamento de dados, existem algumas escolas de pensamento e eu acredito - não tenho 100% de certeza - acho que vi no baralho de Ron que ele vai cobrir algumas delas, então uma que eu vou falar hoje é do CMMI. E este aqui, está disponível para as pessoas; abrange seis categorias diferentes de gerenciamento de dados, 25 áreas de processo, 414 declarações práticas e 596 produtos de trabalho diferentes. Então, quando você pensa em apenas todas as coisas que faz, como gerenciar e arquitetar dados, 596 produtos de trabalho funcionais, não percebeu o quanto fez, certo? Ou o que você realmente não está fazendo. Quando olho para um número assim, é uma das coisas que realmente fica na minha mente. Então, nisso, e o que eu mais gosto nesse particular, é a arquitetura e a tecnologia neutras. Então, isso significa que, se você tem, e a maioria das organizações maiores que eu consultei, trabalhei e implementei ao longo dos anos, elas têm todos os tipos de tecnologias diferentes lá. Portanto, você deseja traduzir o que o DMM significa para as plataformas e as tecnologias que você está usando em seu ambiente específico. Também é independente do setor, portanto não é necessariamente específico para os cuidados de saúde, por exemplo. Os cuidados de saúde têm certeza - seja o BAA ou diferentes tipos de classificação, você precisa traduzir ou analisar diferentes tipos de coisas ao montar seu programa ou seu plano para melhorar seu nível de maturidade de gerenciamento de dados em sua organização.
O que é isso, se não são algumas dessas coisas? Essencialmente, está definindo o quê, mas não dizendo especificamente como fazer isso. Tendo sido uma personalidade muito Tipo A na maior parte da minha carreira, eu gostei quando as pessoas me deram um objetivo e eu pude descobrir como chegar a esse objetivo e não estava, digamos, microgerenciando meu tempo, como chegar lá. É assim que a maturidade do gerenciamento de dados e esses processos com o CMMI estão fornecendo as metas e como você se mede em algumas dessas áreas diferentes. E eles vão te dar um nível. Existem diferentes maneiras de pontuar e medir, seja no nível um até o nível cinco, o que significa que você o otimizou e possui um programa realmente forte.
E para dar uma idéia do que isso realmente significa, tenho uma pequena visão geral do que isso pode significar. Então, aqui, quando você pensa em ter um ciclo de vida do processador de maturidade de gerenciamento de dados, está implementando os processos de suporte, desde requisitos, gerenciamento de riscos, você precisa suportar processos lá, governança de dados e eu sou gentil de encobrir isso, mas essencialmente a governança de dados é um programa completo por si só. Com um glossário de negócios, falamos sobre glossários de negócios e arquitetos de dados para sempre - isso deve ser algo que você tem em sua organização. Alguns desses tipos de tecnologia de catálogo estão sendo desenvolvidos, desenvolvendo um glossário de negócios com o crowdsourcing de informações e coleta e outros enfeites e, você sabe, colocando links em documentos para diferentes perspectivas dos mesmos dados, do campo dos dados ou versão dos dados conforme eles são alterados ao longo do ciclo de vida do valor.
Estes são os tipos de coisas que melhoraram muito desde que comecei na minha carreira. No passado, tínhamos que desenvolver sistemas locais para fazer esse tipo de coisa. Então, estamos olhando para o todo e para o quadro geral, é a estratégia e, em seguida, todas as diferentes partes aqui, desde o gerenciamento até a qualidade em governança. E uma coisa sobre a qualidade dos dados é interessante à medida que o setor se torna mais automatizado e temos, novamente, esses processos digitais com tomada de decisão automatizada. Estou trabalhando muito no espaço de ciência de dados em que algumas dessas ferramentas automatizam decisões e atualizam modelos preditivos em tempo real. Muitas dessas ferramentas e algoritmos exigem e assumem que os dados são bons. Ele precisa que os dados sejam válidos para lhe dar uma boa decisão automatizada. Então, pensando em, você sabe, talvez a qualidade dos dados seja geralmente uma daquelas coisas que as pessoas deixam de lado e não estão levando muito a sério. Mas quando você começa a automatizar a tomada de decisões em modelos para modelagem preditiva e aprendizado de máquina, a qualidade dos dados se torna realmente importante.
Algumas maneiras de medir seu progresso aqui são - e eu deixarei Ron falar sobre isso, ele também tem um deslize sobre isso em sua sessão - eu só vou lhe dar uma olhada rápida, você sabe, esses diferentes níveis nisso. Essencialmente, é uma auto-avaliação, certo? Assim, você analisará sua governança de dados e o que acha que tem alguma coisa em prática. E não fique envergonhado se não o fizer. Como eu disse, existem apenas 33% das organizações que começaram a fazer esse tipo de coisa. Embora, você sabe, esses tipos de programas tenham sido bem-sucedidos - eu estou no setor há mais de 20 anos e certamente estava fazendo esse tipo de coisa anos atrás, talvez não tenhamos chamado apenas isso. O CMMI, eles têm um exercício que você pode auto-avaliar e pode analisar e criar o seu próprio - nesse caso, esse tipo de gráfico de radar - classificou todos esses ângulos ou coisas diferentes. E cada organização, como eu fiz de diferente, sabe, quando eu fazia consultoria e implementação desses projetos, cada organização é única. Serão áreas que serão realmente muito importantes para eles. Talvez, você sabe, é o gerenciamento de processos, o gerenciamento da qualidade ou os riscos - depende do que é, mas você deve procurar e criar uma referência ou uma linha de base e depois pensar no que define seu sucesso.
Nesse sentido, quando você estiver pensando em medir e governar esse tipo de coisa, primeiro desejará garantir algum patrocínio executivo para um programa como esse. Isso é algo que será multifuncional em toda a organização. Portanto, mesmo que Susie Q e John Smith decidam: "Sim, vamos fazer isso. Precisamos fazer isso", eles não podem fazer isso em um silo no país. organização ou mesmo se é de TI. Você realmente precisa ter esse apoio da empresa e dos especialistas no assunto de dados. Eles precisam ter algum tempo. Eles não querem que seja apenas uma tarefa extra. Se você já trabalhou - acho que já fiz algumas tarefas de gerenciamento de dados mestre, projetos antes e qualidade dos dados - e geralmente, você sabe, chega ao negócio e eles dizem: “Oh, administração de dados”. algo que eles estão animados. E eles são como, “Oh, não. Precisamos ter tempo para isso ”, e eles têm. Então você vai querer ter algum compromisso de tempo. Você precisará ter essa bênção do topo. Você quer que seja multifuncional.
Novamente, isso é algo que realmente afeta muitas áreas da organização. E com o GDPR, isso deve facilitar um pouco, porque, novamente, as leis do GDPR e onde esses dados pessoais são usados para seus clientes e usados em toda a organização, isso deve ser um pouco mais fácil se você aplicá-lo, se você tiver aderir ao RGPD. Ficando amarrado aqui. Isso deve ser mais fácil para você fazer. Você deseja atribuir alguma responsabilidade e, em seguida, veja, você vai personalizá-las. Portanto, você sempre olha para esses tipos de orientação que essas organizações fornecem, e geralmente são elas: são diretrizes para você e você implementará para sua cultura em sua organização.
Trabalhar na governança foi realmente muito importante, uma das coisas que alguns dos produtos que desenvolvi quando estava no gerenciamento mundial de produtos na Microsoft eram BI de autoatendimento e permitiam que o usuário comercial e o usuário não técnico de dados brinque com os dados e crie seus próprios relatórios, e muitas vezes a TI recuaria. Portanto, dediquei muito tempo a essa governança e a garantir que os produtos tivessem os recursos corretos, a auditoria e o registro em log e, você sabe, a fazê-lo para que não derrubassem o banco de dados em si. Mas existe uma estrutura que, você sabe, trabalhando ao longo dos anos nesse tópico específico desses tipos de coisas que são muito semelhantes ao gerenciamento de dados também. Você desejará ter essa base que foi estabelecida com o patrocínio executivo para isso e o compromisso entre negócios e TI.
Novamente, falamos sobre alocação de orçamento / tempo e no desenvolvimento de novos processos. Será uma mudança no nível cultural quando você fizer algumas dessas coisas, você sabe, começar a analisar dados. Mas você sabe, é muito importante de uma perspectiva estratégica, novamente. E para você ter uma ideia, aqui está um exemplo, e eu o limpei de um de meus projetos antigos de anos atrás sobre esse tipo de coisa. E, novamente, isso provavelmente é mais do ponto de vista de governança genérica, mas certamente pode ser reutilizado para esses tipos de projetos com o gerenciamento e a evolução de seus processos de gerenciamento de dados e com a sua administração. Você tem um especialista no assunto de negócios, temos administradores de dados aqui, os especialistas no assunto de TI, para diferentes linhas de negócios. Muitas empresas maiores terão seu quadro de padrões corporativos e seus arquitetos corporativos, arquitetos e modeladores de dados. Portanto, haverá alguns especialistas diferentes no assunto, de diferentes níveis. E, novamente, muitos desses - eu odeio ter como exemplo - eles serão personalizados para sua organização e sua cultura.
Uma das coisas quando você está trabalhando com esses projetos é que muitas vezes provavelmente não é o projeto mais empolgante das organizações, nem tão visual quanto as pessoas querem. É engraçado, é uma daquelas coisas que, quando a empresa de consultoria entra ou mesmo em seu próprio grupo de TI ou seu grupo de centro de excelência de BI entra em cena ou seu centro de excelência de análise e vamos trabalhar com dados qualidade e maturidade do gerenciamento de dados, eles podem não estar incrivelmente animados em fazê-lo. Mas você precisa encontrar maneiras de motivá-los e incluí-lo em suas medições. Então, quando você pensa sobre o que vai ser, uma coisa é fazer esse exercício uma vez e atrair as pessoas. E você descobre que eles adoraram o catálogo de dados ou adoram algumas dessas coisas porque isso facilita a vida deles e eles podem descobrir o que os dados significam ou entendê-los, e podem adicionar sua própria perspectiva a eles. E o fato é que os catálogos de dados são provavelmente um dos maiores projetos para ajudar as pessoas a se apaixonarem por isso.
Então, a próxima coisa é mantê-los envolvidos. Como você mantém alguém envolvido que talvez não se importe com isso? É para definir algumas métricas e incluí-las, sua medição e, em seguida, fornecer um aprendizado para quando houver violações e alguma conscientização de que: "Ei, nós estávamos indo muito bem por um tempo e depois não tão bem depois de um tempo." são tipos de coisas em que pensar para continuar. E então, quando você pensa em pontuação, e este é um exemplo do CMMI, é assim que eles pontuam. Novamente, você terá seus próprios painéis, seus próprios KPIs, diferentes maneiras de medir as pessoas em uma organização. Mas você terá diferentes maneiras de pontuar e medir seu próprio sucesso. Meu ponto-chave que você deve tirar disso, ou um gancho para tirar isso, é garantir que você tenha uma maneira de medir o sucesso e que possa celebrar seus sucessos também.
Então, com isso, eu aprecio que você tenha se apegado a esse tópico emocionante, e eu vou falar com Ron, que vai se aprofundar um pouco mais.
Ron Huizenga: Bem, obrigado, Jen. E obrigado a todos por se juntarem a nós hoje. Agora, vou abordar algumas facetas do que Jen falou e aprofundar um pouco mais em determinadas áreas. Mas o que também vou fazer é fornecer um resumo de como você pode, pelo menos, fazer uma autoavaliação de alto nível de algumas dessas áreas também. Porque, como você viu nos modelos CMMI e esse tipo de coisa, é possível aprofundar muito rapidamente com muitos indicadores diferentes. Então, o que realmente queremos alcançar é algo para que você possa ter uma boa idéia de onde sua organização está em um nível razoavelmente alto e depois começar a se aprofundar nas outras. Então, com isso, vou falar sobre eficácia organizacional. E vou basear isso no CMMI e em alguns dos outros padrões ou corpos de conhecimento que surgiram disso ao longo dos anos. E então eu vou falar sobre alguns dos indicadores de maturidade para maturidade de dados e maturidade de processos, porque, conforme analisamos isso, você verá que eles andam de mãos dadas. E, apoiando as perspectivas, Jen falou sobre governança em uma área. E também vou falar um pouco sobre arquitetura corporativa. E então vamos resumir e chegar à mesa redonda.
Se olharmos para ela, há muitos padrões e BOKs - que obviamente são corpos de conhecimento - que foram publicados ao longo dos anos. Muitos destes realmente se originaram do modelo de capacidade de maturidade. E é aí que o CMMI de que Jen estava falando veio. O modelo CMM em si era, na verdade, em 1998. Na verdade, ele foi iniciado por um cavalheiro chamado Watts Humphrey quando ele estava na IBM. Ele teve uma carreira de 27 anos na IBM. Mas seu verdadeiro desenvolvimento ativo desse modelo em particular começou quando ele estava em Carnegie Mellon e foi encomendado pelo Departamento de Defesa dos EUA. Muitos outros padrões foram usados para derivar isso. E algo que é muito bom saber sobre a indústria quando falamos sobre isso em alguns dos outros padrões é que, quando analisamos o momento, também é no contexto das coisas que estávamos vendo na indústria em geral. Foi quando o movimento da qualidade estava realmente começando a se firmar, principalmente na manufatura, e isso se espalhou para outras áreas. Onde estávamos procurando maneiras de melhorar os processos de fabricação, fazendo coisas como gerenciamento de qualidade total, fabricação just-in-time e outras coisas. E muitas das filosofias que surgiram surgiram em todo o corpo de trabalho de qualidade.
E esse é realmente o ponto de partida a partir do qual muitas dessas coisas começaram. Começou na indústria em geral e chegou também a TI e sistemas de dados e processos e informações. Outros padrões que vemos que estão mais intimamente relacionados ou mais específicos com algumas das coisas sobre as quais estamos falando, é claro, o modelo de maturidade de dados, sobre o qual Jen falou um pouco. Há também o modelo de maturidade do processo de negócios do Object Management Group. E vários outros padrões que você pode ter visto que sua organização pode estar enfrentando ou utilizada para diferentes áreas de negócios, principalmente orientadas à TI, como o COBIT, que é o objetivo de controle de informações e tecnologia, ITIL, que geralmente é infraestrutura -focada, com a qual muitos de vocês já lidaram. Novamente, gerenciamento de qualidade total. E, especialmente, quando você analisa coisas como métricas e tudo mais, pode ter visto coisas como controle estatístico de processos também. E, é claro, alguns dos corpos de conhecimento com os quais lidamos são profissionais da informação ou de TI. O corpo de conhecimento em gerenciamento de dados por.
Existe também, equivalente a isso, o corpo de conhecimento da análise de negócios. E o corpo de conhecimento em gerenciamento de projetos. Você pode ter várias ou mais dessas coisas em jogo sendo usadas por diferentes partes interessadas em sua organização ao mesmo tempo. Mas vamos filtrar os BOKs e voltar e dizer: o que é maturidade? E listamos a definição de maduro porque, quando você pergunta o que é maturidade, quando o pesquisa no dicionário, ele realmente diz "você é maduro". Portanto, usar a palavra "maduro" significa realmente ter atingido um nível avançado. estágio de desenvolvimento - é claro, muito genérico. Mas o que realmente estamos vendo aqui é avançar o que estamos fazendo para um nível cada vez maior de conquistas à medida que avançamos. E quando você olha para muitos dos padrões, como verá, o CMMI em particular e o modelo de maturidade de capacidade realmente baseiam as coisas em uma escala de cinco pontos, por isso nos fornece uma maneira gradual de olhar e dizer, como estão estamos realmente evoluindo nessa escala em como estamos crescendo?
Porém, quando observamos a maturidade, em termos de alcançar a maturidade organizacional nas coisas em que estamos interessados, precisamos estar em equilíbrio. Você precisa atingir a maturidade dos dados, e falaremos sobre alguns dos critérios que você deve fazer lá, mas você precisa alcançar a maturidade do processo ao mesmo tempo. São dois lados da mesma moeda e têm que andar de mãos dadas. Você não pode ir, digamos, de zero a cinco em uma escala de maturidade de dados sem aumentar a maturidade do processo, e o mesmo se aplica à maturidade do processo. Ambos estão juntos e se juntam para o passeio enquanto você está evoluindo nos diferentes estágios. E eu vou falar sobre isso um pouco mais em um slide futuro aqui. As outras coisas que precisamos compreender são a maturidade dos dados e do processo, que são fundamentais para a arquitetura corporativa e para algumas das coisas de governança de que Jen também estava falando. Nós capacitamos aqueles que atingem a maturidade em algumas dessas coisas que estamos tentando fazer.
Agora, no slide que Jen disse que eu iria falar um pouco mais detalhadamente. Eu peguei apenas algumas categorias e, usando a escala CMM aqui, e na verdade tenho a minha, adiciono zero em termos de, no topo da escala, porque pode haver certos casos em que você realmente não fez qualquer tração nesses casos. Portanto, essas são apenas formas de reconhecimento que ocorreram. Portanto, se analisarmos a governança de dados em particular, você poderá começar do zero porque não possui nenhum programa de governança de dados. E quando você começa a amadurecer nas diferentes áreas, uma vez que você começa a apresentá-lo no nível do projeto, no nível do programa, nas divisões e, finalmente, em toda a empresa, é assim que, do ponto de vista da governança, você está realmente amadurecendo e crescendo como uma organização ao fazer isso.
Outras facetas disso, como o gerenciamento de dados mestre, você pode começar do zero, sem classificações de dados de matéria formal. Depois, você chega a um ponto em que reconhece que possui dados mestre e começa a classificar, mas não está integrado. Então você começa a trabalhar para repositórios integrados e compartilhados. Então, quando você entra em um ambiente padronizado, é quando você procura prestar serviços de gerenciamento de dados. E, à medida que você avança, você estabelecerá administradores de dados mestre e, eventualmente, um conselho de administração de dados que realmente olha isso seriamente o tempo todo. Quando você olha para o seu ambiente técnico, os aplicativos e os bancos de dados que você possui da perspectiva da integração de dados, novamente, em um ambiente imaturo, você terá várias interfaces ad hoc, ponto a ponto e esse tipo de coisa. E à medida que você progride, começará a introduzir algumas ferramentas e padrões comuns. Então você começará a olhar para plataformas de integração comuns à medida que crescer. E à medida que você se padroniza, estará trabalhando no middleware padronizado e em possíveis coisas fáceis, como barramentos de serviços corporativos, modelo canônico, categorize todos os seus dados em sua organização e também vinculando coisas como regras de negócios em seu repositório e outras coisas. de coisa. E depois, indo ainda mais longe, onde você o integra totalmente na cultura organizacional. E, claro, a qualidade é fundamental. Como Jen falou, muitas das decisões e muitas ferramentas lá em cima assumem que você possui dados de alta qualidade com os quais está trabalhando. Portanto, a qualidade dos dados é algo que é fundamental para alcançar a maturidade dos dados.
Novamente, quando você olha para os dados, pode haver muitos silos e dados dispersos em ambientes imaturos. Você pode ter inconsistências que são aceitas. E então você começa a trabalhar nisso, reconhecendo o inconsistente e depois começa a analisar o planejamento. E se você observar os ambientes gerenciados aqui, algo muito importante aqui é a limpeza de dados no consumo para poder usá-los na tomada de decisões. Então, o que realmente estamos falando é sobre limpeza de dados, onde vamos carregá-los em data warehouses e outras ferramentas de apoio à decisão. E isso é análogo ao que costumávamos ver no tipo de indústria de fabricação de dados em que as pessoas construíam produtos, elas percorriam a linha de montagem e, no final, você inspecionava o produto e dizia: “Ah, aqui temos defeitos. ”Novamente, uma coisa que você nunca pode fazer é nunca melhorar a qualidade de um produto, inspecionando-o no final. Você pode ver os problemas com ele e, em seguida, pode tomar medidas para melhorar os próximos e outros que descem a linha depois dele, mas você nunca vai melhorar, inspecionando-o no final. Portanto, é nesse ponto que, à medida que avança, especialmente nos dados, você passa mais de uma inspeção e um ponto de vista de limpeza no local de consumo em que começa a tentar incorporá-lo na fonte, exatamente de onde você obtém o dados, os processos que atuam sobre esses dados, garantindo que esses dados sejam precisos e adequados ao consumo em todos os processos ao longo do caminho. À medida que você avança, você começa a desenvolver e obter KPIs de qualidade e realmente começa a desenvolver essa abordagem de prevenção à qualidade dos dados à medida que avança.
Em termos de comportamentos organizacionais ou coisas que você vê, se você acha que tem um problema ou não sabe, você pode estar, se houver uma fase de negação em sua organização, que me diz que você está deprimido um nível zero ou potencialmente se movendo para um. Se houver muito caos nos seus dados e tentar resolver essas inconsistências, você provavelmente estará no nível um. Quando você ainda está no modo reativo, está migrando para o gerenciado, mas não será padronizado até ter um ambiente de dados muito estável, abrangendo a governança, a qualidade, o gerenciamento de dados mestre e os dados. integração, para citar apenas alguns dos pontos. E, novamente, depois de superar isso, é quando você começa a adotar estilos de gerenciamento realmente proativos. Se você chegar à parte em que possui um comportamento muito preditivo e também as análises para fazer backup e os KPIs para fazer backup em sua organização, quando analisamos isso e sobrepomos algumas coisas, há outras coisas que podemos veja sobre as organizações e onde elas estão. Vejamos o foco principal de TI em uma organização. Se o seu foco principal em TI ainda estiver em tecnologia e infraestrutura, você provavelmente estará no final menos maduro da escala. Mas quando você realmente se concentra na informação e na capacitação de negócios estratégicos que possibilitam a informação, está se aproximando do final maduro da escala. Além disso, quando você o analisa da perspectiva dos dados, se você está no nível mais baixo, tem um alto risco de dados e se está no nível mais alto, reduziu o risco relacionado aos dados. E o outro lado disso é a geração de valor da organização. Menor maturidade dos dados significa que você provavelmente tem um nível bastante baixo de geração de valor, principalmente em termos dos dados que possui em sua organização. E, à medida que você aumenta a escala, obtém uma alta geração de valor.
Vejamos isso em termos de modelagem de dados em si. Às vezes, a modelagem de dados tornou-se o enteado ruivo. E a modelagem de dados é fundamental para alcançar a maturidade dos dados. Então, eu só quero falar sobre alguns dos sinais reveladores sobre como a modelagem de dados se vincula a isso. Se estiver sendo usado apenas para documentação ou para geração simples de bancos de dados físicos para aplicativos pequenos e esse tipo de coisa, você provavelmente está no nível um em termos de maturidade de dados. Quando você começa a adotar e reconhecer os diferentes tipos de modelos, incluindo conceitual, o modelo lógico e a modelagem física, onde também está, você sabe, basicamente você está conduzindo o design. Você está realmente usando-o como ponto de vista de design e, então, está no nível um.
Quando você começa a analisá-lo de um nível mais corporativo, incluindo a criação de modelos corporativos ou canônicos, a introdução de conceitos e vinculação em vários modelos, a linhagem de dados e a criação de metadados de governança diretamente em seus modelos, você está começando a nível três e, em seguida, avançar para metadados de governança completa, integração de glossário comercial, etc. Observar o ciclo de vida e a cadeia de valor dos dados é quando você realmente chega ao nível quatro. E, novamente, modelagem totalmente integrada com glossários de negócios, metadados, sendo capaz de impulsionar coisas como análises de autoatendimento, é realmente quando você atinge um estado bastante maduro.
Como parte integrante disso, quero falar sobre o ciclo de vida dos dados muito brevemente. E a razão pela qual quero falar sobre isso é o ciclo de vida dos dados, infelizmente, muitas vezes é ignorado. E realmente descreveu como um elemento de dados é criado, lido, atualizado ou excluído e os processos que atuam sobre ele em toda a organização. Portanto, aqueles de nós que estamos no setor há muito tempo nos referimos a isso como CRUD, porque é a criação, leitura, atualização e exclusão. Mas precisamos entender isso em um nível fundamental quando lidamos com os dados em nossa organização. Muitos fatores entram em jogo. Quais são as regras de negócios que atuam sobre ele? Quais são os processos de negócios que consomem, produzem ou alteram os dados? Quais são os aplicativos que realmente implementam esses processos de negócios para permitir que você faça isso? Tudo isso entra em jogo em termos do ciclo de vida dos dados.
E, novamente, Jen fez alusão a isso antes - pode não haver necessariamente uma fonte de verdade. E pode haver várias maneiras de criar um elemento de dados específico. E você pode realmente ter que entrar, coisas diferentes chegam através de vários sistemas ou várias entradas que você precisa reconciliar e resolver para descobrir qual é a fonte adequada de dados para essa decisão específica naquele momento. Pode haver várias variantes dos dados para diferentes propósitos em uma organização. Para conseguir isso, é necessário modelar processos de negócios, linhagem de dados que inclui fluxos de dados, integração e que inclui coisas como o ETL, para extrair, transformar e carregar para o seu data warehouse, data mart e áreas de preparação. e, é claro, os links de dados do lado de big data também entram em jogo. Ao extrair essas informações do data lake, você precisa saber como as está consumindo e como as está usando. Em termos do próprio ciclo de vida, é realmente como estamos criando ou coletando novos dados, como os classificando - porque você precisa classificá-los para entender e trabalhar com eles de maneira eficaz - como você os armazena, como está usando, como você está modificando esses processos de negócios, onde estão sendo compartilhados na organização - e muito importante: retenção e arquivamento. Quanto tempo você retém os dados? Quando você arquiva? Quando você acaba destruindo esses dados? Todas essas coisas devem ser consideradas no seu ciclo de vida dos dados e você deve fazer tudo isso para alcançar um alto nível de maturidade dos dados em sua organização.
Agora, por outro lado, eu disse que eles são como gêmeos, onde você precisa falar sobre a maturidade do processo em conjunto com a maturidade dos dados - eles andam de mãos dadas. Novamente, eu tenho algumas coisas diferentes aqui e - não se preocupe, não vou ler tudo isso, mas apenas uma espécie de lista de verificação -, novamente, você pode começar a autoavaliar a localização da sua organização em termos de da maturidade do processo. Vejamos as coisas do direito inicial através das páginas otimizadas novamente. Novamente, estamos usando a mesma escala de cinco pontos que foi derivada do modelo de maturidade de capacidade. Se você observar coisas como o foco, se estiver em um nível mais baixo ou em um nível inicial de maturidade do processo, poderá descobrir em sua organização que as pessoas estão realmente confiando em seus próprios métodos para realizar seu trabalho. E você pode ver alguns heróis e esse tipo de coisa para conseguir fazer as coisas. Então você começa a chegar a um ponto em que é mais proativo, onde sua gerência assume a responsabilidade pelas unidades de trabalho e pelo desempenho. Então você começa a evoluir os processos integrados padrão. Em seguida, a estabilidade e a reutilização do processo. Em seguida, você começa a ver mais uma cultura de mentoria e gerenciamento estatístico para calcular as métricas e os KPIs relativos a esses processos e, finalmente, ao nível máximo de otimização.
Quando você olha para o gerenciamento de trabalho, pode optar por ir de uma área em que há níveis inconsistentes de gerenciamento de trabalho para mais gerenciados, onde equilibra pelo menos em um nível mais alto seus compromissos com os recursos. Depois, chegue a um ponto em que você esteja tendo uma organização mais adaptável ou ágil para poder padronizar seus processos, mas adaptá-los para o melhor uso em diferentes circunstâncias da organização. E quando você avança, é aí que o empoderamento é muito importante, e isso significa que todos intuitivamente entendem o que está acontecendo e a equipe possui os dados do processo, para que possam avaliar e gerenciar seu próprio trabalho.
Mais uma vez, voltando à analogia da fabricação - quando vimos que, quando começamos a modernizar nossas linhas de montagem e tudo mais na indústria, começamos a falar sobre a qualidade total e o empoderamento dos trabalhadores, mesmo na linha de montagem, onde se alguém visse algo errado em qualquer estágio específico da produção, as pessoas tinham o poder de apertar o grande botão vermelho e desligar toda a linha de montagem até que os problemas fossem resolvidos antes que as coisas continuassem. E é esse tipo de mentalidade e tipo de cultura que procuramos em torno de dados em nossos processos para garantir que realmente otimizamos nossos dados e processos em nossa organização.
Outros indicadores de sua cultura - sua cultura está estagnada em termos de nenhuma base identificável para um comprometimento real na melhoria de seus processos de negócios? Existe uma delegação de responsabilidades que estamos vendo mais adiante? E, à medida que você avança, você ainda pode ter silos, mas, ao começar a avançar em termos de cultura e coisas que está fazendo no seu processo de negócios, também está desmembrando esses diferentes silos de negócios e aproveitando processos em toda a organização. É muito importante que, à medida que você chegue ao estágio do evento, você realmente colecione métricas de qualidade e, em vez de instintivamente, esteja realmente coletando métricas de qualidade e dispondo de métricas para prever sua capacidade no desempenho de seus negócios operações, e isso é extremamente importante.
Em termos de arquitetura, vamos falar sobre isso, porque muitos de nós aqui estamos em TI ou sempre olhando para ele. Novamente, os mesmos tipos de coisas que vimos nos dados. Temos sistemas de TI desesperados se você realmente está no estágio inicial da maturidade do processo. Depois de começar a gerenciar seus processos, você verá alguns serviços sendo configurados, onde realmente está adotando uma abordagem mais baseada em serviços. Então, se você se padronizar, verá mais uma adoção de serviço completo em termos de dados e serviços e serviços de processo e esse tipo de coisa, até onde você obtém um serviço completo ou uma nova arquitetura. E, finalmente, para uma empresa totalmente orientada a processos que utiliza seus dados.
Novamente, os mesmos tipos de escalas quando olhamos para isso. Em termos de produtividade, com um baixo nível de maturidade do processo, você verá baixos níveis de produtividade e alta maturidade do processo, uma produtividade muito maior. E a qualidade anda de mãos dadas com isso também. O mesmo ocorre com os dados - se você estiver com um baixo nível de maturidade, verá um alto nível de risco e também um alto nível de desperdício. Porém, quanto maior o seu nível de maturidade, você diminuirá esse risco e reduzirá o risco significativamente. Em termos de algumas das coisas que você pode ver como tipo de sintomas ou indicadores em uma organização, se a filosofia principal é baseada em redução de custos, você provavelmente está em um nível baixo de maturidade do processo. Em seguida, ele se formará e passará a olhar mais de perto para a eficiência em sua organização e, quando chegar a um nível muito maduro, focará na geração de valor novamente.
De uma perspectiva de gerenciamento organizacional, se o caos reina, normalmente é um sintoma de, novamente, organizações com baixa maturidade de processo. Mas você começa a se concentrar no que eu chamo de mais mentalidade de gestão, onde - e pode haver alguma gestão por decreto ou imposição de coisas - onde você realmente está, quando chega aos níveis mais maduros, sua gerência se traduz em mais liderança. Em outras palavras, a filosofia de melhoria está incorporada na cultura e, desde o CEO, eles estão promovendo toda essa filosofia de melhoria de processos e melhoria contínua e contínua em sua organização como um todo.
Em termos de modelo de processo - e analisarei essas coisas rapidamente aqui - novamente, vejamos os modelos de processo à medida que eles se vinculam à maturidade do processo. Novamente, muito parecido com o que vimos na maturidade dos dados, onde em níveis baixos ou nível um, você pode estar apenas documentando processos ou o processo de estado atual, mas realmente não o está usando em termos de levar as coisas adiante. Quando começar a amadurecer, você usará a modelagem de processos de negócios para impulsionar o gerenciamento de processos de negócios reais na organização e evoluirá ainda mais onde estiver usando e atualizando continuamente esses modelos para direcionar a melhoria de processos para onde você finalmente chegar ao design do processo. E então, quando você amadurece, ou, sabe, o que normalmente vê em organizações enxutas ou que adotaram programas de maior qualidade, como o Sigma, é aí que você tem a mentalidade de melhoria contínua e está arraigada na modelagem de sua organização. Assim como usamos projetos de engenharia para construir produtos, sejam aviões, prédios e arranha-céus e esse tipo de coisa, estamos confiando em nossos modelos para realmente impulsionar nossos negócios, porque esse é o elemento de design que realmente impulsiona nossos elementos organizacionais .
Agora, novamente, eu não vou passar por essa e todas as palavras aqui em detalhes. O que fiz foi pegar esses dois slides mais simples da grade e escolhi várias palavras que foram usadas em alguns desses outros descritores para a maturidade dos dados e a maturidade do processo. Então, quando você olha para isso depois do fato, pode começar a pensar em algumas das palavras que vê saindo em suas próprias culturas internas em termos das coisas que estão sendo ditas. E isso ajudará você a começar a classificar onde, como organização geral, estamos começando a se encaixar nessa escala de maturidade geral. Portanto, se você vê coisas como inconsistência ou estagnação ou ineficiência surgirem com frequência ou caos, normalmente você estará na extremidade inferior da escala. Quando você começa a pensar em coisas como melhoria contínua, alinhamento estratégico, uma abordagem preventiva de defeitos e qualidade e esse tipo de coisa, integração total e você está falando sobre as melhores práticas em vantagem competitiva, é aí que você se vê no otimizador, na extremidade superior da escala.
Novamente, algo que quero destacar também que, quando você começa a analisar a governança de dados, em particular quando analisa a parte inferior da escala, está nos estágios iniciais, a governança de dados pode ser introduzida apenas em níveis de projetos individuais. Você precisa evoluir para um ponto em que a governança de dados e o objetivo específico sejam da governança de dados do projeto e tenha evoluído por meio da governança de dados por programa e divisão, onde novamente é de toda a empresa e incorporado à organização como um todo.
Eu falei sobre o fato de que esses são realmente gêmeos que trabalham juntos em termos de maturidade dos dados e maturidade do processo. Para alcançar essa maturidade, em ambos os lados da escala há uma jornada e você não pode pular etapas. Se você estiver no zero, terá que evoluir através dos estágios um, dois, três, quatro e finalmente chegar a cinco. E existem muito poucas organizações no mundo que estão na verdade em cinco. Portanto, muitas organizações ficariam mais do que felizes em estar em um ponto em que três e então poderiam usá-lo como um trampolim daqui para frente. E, novamente, você não pode ir, não pode ter quatro anos na maturidade de dados e um na maturidade do processo. Simplesmente não funciona porque eles estão tão entrelaçados que você precisa entender e ter uma boa capacidade de lidar com seus dados e processos em conjunto.
Uma boa analogia para pensar nisso como é, em sua jornada em direção à maturidade organizada, vamos assumir que sua equipe é composta por duas pessoas: uma é a maturidade do processo e a outra é a maturidade dos dados. Você está correndo por uma pista de obstáculos e está amarrado com uma corda curta. E para chegar ao final desse curso, isso significa que vocês dois precisam passar, não apenas todos os obstáculos, mas precisam passar por todos os obstáculos quase ao mesmo tempo ou muito perto um do outro para serem capaz de seguir em frente e chegar ao próximo obstáculo. Essa é realmente uma boa maneira de pensar em equilibrar a maturidade do processo e a maturidade dos dados. Portanto, em outras palavras, você pode ser um pouco centrado no processo e um pouco centrado nos dados, mas será um indicador importante e não haverá muitas lacunas para realmente mostrar os níveis.
E então, quando analisamos novamente a partir da governança de dados, uma das coisas que eu gostaria de salientar, caso você não estivesse ciente, é que a DAMA realmente lançou o Corpo de Conhecimento em Gerenciamento de Dados Volume Dois no início deste ano, e as coisas que mudou, existe a roda DAMA real. Na verdade, eu o representei um pouco diferente, onde a governança de dados está no centro e as dez categorias diferentes ao redor da roda. Algo que é muito importante ver aqui é a modelagem e o design de dados, na verdade, tem suas próprias áreas no volante agora - ele meio que se misturou às outras, anteriormente. Uma das coisas que é um ponto muito fundamental aqui é a modelagem de dados, em particular, é fundamental para todos esses outros aspectos, porque, se estamos fazendo modelagem de dados de nossos bancos de dados ou os metadados com os quais estamos lidando, a modelagem de dados tem um papel a desempenhar. tocar em todas essas outras peças que estamos falando. E a modelagem de processos também tem um papel a desempenhar em muitas dessas coisas, porque, além de entender os dados em si, precisamos entender como eles são usados e é assim que a modelagem de processos realmente nos ajuda a fazer isso.
Agora vamos mudar um pouco de rumo e falar sobre arquitetura corporativa. E os modelos também são cruciais para a arquitetura corporativa. E eu estou baseando isso no exemplo e este é o framework Zachman que estou mostrando aqui muito rapidamente. E quando você olha para isso, vê várias coisas aqui. Você vê o que, como, onde, quem, quando e por que está no topo da escala. E então você passa por níveis mais detalhados de elaboração, se desejar, em termos dos tipos de modelagem ou tipos de coisas que você está elaborando em termos da arquitetura corporativa, desde um nível contextual muito alto até um nível detalhado, incluindo implementação física. Se você olhar para as primeiras colunas, o que é muito intensivo em dados e envolve dados. O como é muito orientado por processos. E se você observar os outros aspectos, usará uma combinação de modelagem de processos e dados em termos de conduzir o restante das informações. Você terá dados sobre todas essas coisas diferentes e seus modelos de processos também amarrarão as coisas, como onde as coisas acontecem, a responsabilidade. E também em termos da modelagem de processos que fazemos também em nossas ferramentas, você pode começar a vincular isso às metas, aos relacionamentos e às regras de negócios que estão impulsionando essas coisas diferentes que você está fazendo.
De uma perspectiva geral da estrutura de Zachman, uma das boas maneiras de pensar sobre isso também é que você é orientado pelo modelo e está passando por diferentes níveis. Então você está começando com um escopo de alto nível e o contextual. Você está evoluindo para modelos de negócios, para modelos de sistema, modelos de tecnologia e também uma representação muito detalhada dos modelos técnicos. E, novamente, os dados representam o que, processo é o como e é realmente uma combinação dos dados e do processo que interagem com todas as outras características aqui.
Com base nisso, não é coincidência que a maneira como vemos a ideia de arquitetura corporativa seja baseada um pouco diferente do que algumas outras podem. Frequentemente, você ouvirá sobre os quatro pilares da arquitetura corporativa: dados, aquisição, negócios e arquitetura técnica. Nós olhamos para isso um pouco diferente do que isso. Vemos a arquitetura de dados como a base fundamental que impulsiona toda a arquitetura corporativa por dois motivos. Um, foi onde começou. Até coisas como a estrutura Zachman cresceram principalmente da arquitetura de dados e, em seguida, cresceram para abraçar os outros aspectos da arquitetura. E dois, porque o laço fundamental entre processo e dados. É por isso que vemos a arquitetura comercial como o pilar central da arquitetura corporativa. E então, é claro, isso é complementado pela arquitetura de aplicativos e arquitetura técnica, que são facilitadores de necessidade absoluta, para nos permitir impulsionar a verdadeira ativação corporativa. Agora, quando analisamos isso em termos de ER Studio Enterprise Team Edition, nossa plataforma de modelagem integrada, é assim que entra em cena. E este é um diagrama de contexto de alto nível de algumas das modelagens que fazemos e alguns dos fundamentos por trás disso. E isso é realmente motivado, é realmente diagramado em um diagrama de processo. Portanto, quando analisamos nossa parte da arquitetura de dados em particular e nossa arquitetura de negócios abaixo, fornecemos ferramentas baseadas em funções.
E quando você olha para a nossa ferramenta de arquiteto de negócios no canto inferior esquerdo, é onde normalmente trabalham analistas de negócios e arquitetos de negócios. E eles geralmente se concentram em alguns dos processos de negócios e começam a expulsá-los. Mas eles também estão focados no quê. Então começamos a modelar dados conceituais e esse tipo de coisa. Podemos alavancar e trazer esses componentes de modelagem conceitual para a nossa ferramenta de modelagem de dados e para o arquiteto de dados, onde eles são detalhados em modelos de dados lógicos e, é claro, finalmente nos modelos físicos, para que possamos gerar os bancos de dados físicos. E também podemos recuar para que os modelos conceituais também sejam atualizados no espaço da arquitetura de negócios. Uma coisa muito importante aqui é apoiar os diferentes tipos de modelagem. Então, novamente, o BI é muito importante e os lagos de dados e esses tipos de coisas, então na verdade fazemos modelagem também e também como parte disso, modelagem de linhagem de dados. Portanto, não apenas o ETL em termos de como você faz o mapeamento de seus modelos físicos em seus modelos dimensionais para data warehouses ou mesmo trazendo coisas de seus lagos de dados e vendo como eles são mapeados, podemos unir todas essas coisas. Além de encaminhar a engenharia reversa de outras plataformas de modelagem, de plataformas de big data.
E também coisas como ferramentas ETL, para que possamos começar a derivar diagramas de linhagem de dados diretamente das especificações ETL que você pode ter em seu próprio ambiente. Também é muito importante saber que tivemos que expandir além da modelagem relacional. Temos certas plataformas como Hive e particularmente o MongoDB, agora estamos começando a falar sobre armazenamentos de documentos, onde temos conceitos como objetos incorporados e matrizes. Na verdade, expandimos a notação para podermos acomodar esses tipos de modelos, porque é um conceito não relacional. Tudo o que criamos na ferramenta de arquiteto de dados em termos de artefatos de dados, sejam entidades lógicas ou tabelas físicas e seus atributos, também pode ser enviado de volta à modelagem de processamento de negócios. Portanto, ao elaborar seus modelos de processos de negócios de um nível alto e descer para um nível inferior, é possível vincular os elementos de dados reais. Para que você possa agir, podemos especificar as matrizes CRUD do que realmente está acontecendo. Isso está dando a você o ciclo de vida dos dados de que falei com a criação, leitura, atualização e exclusão no nível do processo. Além disso, fazemos a modelagem completa do processo de BPM com nosso próprio conjunto de sobreposições, para que você possa começar a vincular estratégias de negócios e objetivos de negócios. Além disso, também podemos vincular os aplicativos que estão implementando esses processos de negócios, tudo do ponto de vista orientado por modelo.
Outras coisas são extremamente importantes também em nossos modelos de dados. As características de controle de dados ou características de qualidade de dados dominadas e geridas. Você pode definir e criar seus próprios metadados para as características que deseja rastrear, e isso significa que agora você está usando seu modelo como modelo para conduzir isso por toda a organização, em seus repositórios de metadados e tudo mais. E, é claro, uma das limitações da modelagem, muitos anos atrás, quando muitos de nós começamos a fazer isso, é que produziríamos esses modelos. O que faríamos? Nós os imprimíamos, os colocávamos na parede, possivelmente para os membros da equipe compartilharem e esse tipo de coisa. O verdadeiro valor disso é poder compartilhar e colaborar com nossas organizações. É por isso que temos uma abordagem orientada a repositórios para onde fazemos check-in e check-out de nossos modelos e espaços de trabalho. E os compartilhamos com nossos constituintes que são a organização, sejam eles outros interessados técnicos, usuários de negócios e esse tipo de coisa. E também vincule isso à nossa plataforma de colaboração chamada Team Server.
Conversamos sobre glossários e termos de negócios anteriores e a importância disso e o desenvolvimento desse vocabulário para os negócios. Tudo isso acontece no Team Server, onde usuários, usuários corporativos podem colaborar nesses termos. Eles são visíveis, utilizáveis no arquiteto de dados, por exemplo, perto de modelos de dados e, é claro, muitos desses glossários de negócios geralmente se originam de alguns dos dicionários de dados que criamos em nossos modelos de dados. Podemos empurrá-los para fora - também a partir das ferramentas do arquiteto de dados, um ponto de partida é o glossário de negócios, onde elas podem ser refinadas ainda mais, e também com o gerenciamento de alterações.
Isso foi muito. Apenas para resumir, algumas coisas sobre as quais falamos é tentar uma verdadeira maturidade organizacional, você precisa de uma abordagem equilibrada que inclua a maturidade dos dados e a maturidade do processo. Você não pode conseguir um sem o outro. Novamente, fundamental, você precisa ter os dois e contar com isso, especificamente, modelagem de dados e modelagem de processos para arquitetura corporativa e governança de dados e governança de processos, bem como em suas organizações. A arquitetura corporativa realmente a une em termos de olhar para essas diferentes facetas e perspectivas. Você precisa de uma base sólida de arquitetura de dados para fazer isso e precisa de modelagem de processos integrados para fornecer esse contexto de negócios e permitir que você conduza seu processo de negócios e seu consumo de dados adiante. Mais uma vez, mais importante do que nunca. Posso dizer que o que há de novo é novo novamente. Portanto, modelagem de dados, modelagem de processos, linhagem, metadados e glossários são fundamentais para conseguir isso e o ER / Studio Enterprise Team Edition é uma plataforma colaborativa que reúne tudo isso.
E com isso, podemos avançar para as perguntas.
Eric Kavanagh: Tudo bem.
Ron Huizenga: Nós iremos até você, Eric.
Eric Kavanagh: Ron, tenho de lhe dar uma gorjeta por todo o esforço que você dedica para documentar esses diferentes processos e estruturas. Isso é muito material que você tem lá. Acho que a grande questão que tenho é quem deve supervisionar essas coisas em uma organização, porque você aborda muitas coisas diferentes. Você imagina processos, será um chefe de operações ou alguma pessoa de operações. Ciclo de vida dos dados, você acha que talvez seja um diretor de dados. Você está tocando tantas partes e componentes diferentes nos negócios. Como você encontra a pessoa ou grupo certo de pessoas e é um comitê de direção? O que é isso? O que você pode nos dizer sobre quem deve fazer isso em uma organização?
Ron Huizenga: Sabe, essa é uma pergunta interessante. Na verdade, podemos passar um dia discutindo os méritos de várias abordagens diferentes. Mas algo que eu definitivamente vi, como eu estava consultando antes de assumir a função de gerenciamento de produtos, é que quando olhei para a organização, isso faz parte do problema: obter a propriedade e levar as pessoas a se apropriarem disso. E quando analisamos as disciplinas como a modelagem de dados e até a modelagem de processos de negócios, ou mesmo nos primeiros dias, a diagramação de fluxo de dados e esse tipo de coisa, esse tipo de crescimento surgiu da TI. Mas, à medida que avançamos, acho que agora reconhecemos cada vez mais que isso realmente precisa ser direcionado aos negócios. Então, você realmente deseja que a propriedade disso esteja nos negócios.
E vou ofender algumas pessoas de TI aqui, mas acredito firmemente que a razão pela qual vimos a evolução da função de diretor de dados é que a função de CIO falhou nisso na maioria das organizações. E isso ocorre porque muitos dos CIOs estão tecnicamente focados, em vez de dados e processos. Então eu acho que você realmente precisa disso, provavelmente precisará de algum tipo de comitê diretor nas organizações maiores. Mas isso realmente precisa pertencer à empresa. Eu argumentaria que seus negócios, sua modelagem de processos, sua modelagem de dados, todos precisam pertencer à empresa, porque isso lhe dá a capacidade de garantir que a TI, quem é a guardiã dos dados e implemente esses processos através do que eles você está criando, você tem esse martelo para garantir que isso aconteça se for de propriedade da empresa.
Eric Kavanagh: Sim, acho que concordo com isso. Mas Jen, o que você acha disso?
Jen Underwood: Então é realmente interessante. Isso é o que eu estava falando quando disse que levar as pessoas a se importarem e serem interativas é provavelmente uma das principais coisas. Em um ponto, eu escrevi um white paper sobre, era a governança de BI de autoatendimento muito semelhante a isso. É uma questão de conseguir isso, encontrar uma maneira de motivar as pessoas, o lado do valor comercial, para fazer com que elas se importem com isso. E então, quando eles veem, ou descobrem, se é a catalogação de dados ou o ângulo que for necessário. Talvez esteja reduzindo os custos de remessa, colocando algo que alguém responsabiliza na organização, é assim que você pode cuidar disso. E sim, o negócio absolutamente. Os especialistas no assunto de negócios vão fazer ou quebrar.
Eric Kavanagh: Isso é difícil. Eu acho que você sempre quer ter esse consórcio de partes interessadas de toda a organização. Claro, você não quer paralisia na análise. Você não quer burocracia por causa da burocracia. O que você deseja é que a organização tenha um plano de ação e tenha essas coisas documentadas. Sabe, eu acho que quando você começou a falar sobre modelagem de processos de negócios, isso era quente há 25 anos, mas era principalmente desassociado dos negócios reais. Acho que, pelo menos em alguns setores, você pode extrair grande parte desse processo do software real que executa as coisas. Mas acho que hoje em dia temos que encontrar uma maneira de equilibrar esses dois mundos, certo, Ron? Você deseja ter modelos de processo atualizados, atualizados e refletindo o que realmente está acontecendo. Então você não quer que seja apenas um exercício separado, onde fica, fica em uma prateleira em algum lugar. Mas isso é meio que um pouco desafiador, certo? Porque nem todos os sistemas operacionais estão alinhados com esse tipo de código executável. Mas o que você acha?
Ron Huizenga: Absolutamente. E é interessante porque uma das coisas que eu olho é quando as pessoas, você sabe, nos tornamos uma sociedade de gratificação instantânea. As pessoas pensam: “Oh, nós simplesmente vamos comprar algumas ferramentas e fazer isso funcionar para nós.” É como se você não comprasse a maturidade do processo. Você não vai comprar maturidade de dados. É trabalho duro. Você precisa arregaçar as mangas e fazer isso acontecer. E o mecanismo para fazer isso acontecer é a modelagem. É muito complexo para não ter uma representação visual, não apenas do estado atual em que você está trabalhando, mas para poder projetar como vai melhorar esses diferentes processos de negócios. Você precisa dessa estrutura visual para entender o impacto dessas mudanças.
Eric Kavanagh: Isso é realmente - estou apenas twittando; Estou twittando isso agora - "Você não vai comprar a maturidade do processo, não vai comprar a maturidade dos dados". Posso concordar completamente com essas duas coisas. E Jen, eu te trago para seus pensamentos. E vou colocar outra pergunta em cima disso. Um dos participantes está perguntando: o que significa empresa impulsionada por processos ou maturidade de processos? Jen, você pode falar com isso?
Jen Underwood: Na verdade, posso falar um pouco melhor da pergunta anterior. Quando penso, verdade seja dita, é a primeira, você sabe, comprando ferramentas. Esse foi um comentário muito bom, porque é verdade. Mas o que vou dizer é muito melhor. Então, reviso muitas soluções, vejo diferentes espaços e os testo. O que está melhorando é descobrir dados, marcar e, pelo menos, dar-lhe um grande começo de corrida e também fazer isso, quando digo menos doloroso, é quase divertido. Imagine um catálogo de dados ou um projeto MDM divertido. É, e você tem pessoas em uma organização que está usando esses dados, sejam relatórios ou outros tipos de coisas, e acho que alguém que estava na linha havia dito, ei, recebendo pessoas que se preocupam com seu plano de desenvolvimento individual. Sim, até suba mais um nível. É pegar essas coisas e dizer que agora reduzimos os envios mal direcionados em 30% e é assim que poupa dinheiro. É apenas gerenciar melhor nossos dados. São esses tipos de coisas e você põe dinheiro em torno dele e você o torna divertido. Ou você o torna interessante e relevante para o que eles estão fazendo. Acho que esse tipo de mágica está faltando em muitos desses compromissos que as pessoas tentam fazer isso em uma organização, e está parado.
Eric Kavanagh: Sim, esse é um bom argumento. E, Ron, voltando ao seu comentário há alguns instantes sobre a importância de ter uma estrutura visual, acho que é absolutamente verdade porque muitas vezes, se as pessoas não conseguem ver algo, é realmente difícil entender o que é isso. significa, e certamente, quando você começa a falar sobre processos complexos com interdependências e pontos de controle e todas essas coisas, você precisa mapeá-lo em algum lugar em algum momento e, idealmente, está fazendo isso com um software com funcionalidade incorporada ao catálogo, por exemplo. Por exemplo, quais transformações ocorreram usando linhas diferentes deste ponto para esse ponto. Ou o que está disponível neste ponto de controle. E eu estou meio que referenciando minha história em gerenciamento de riscos lá, onde um ponto de controle é qualquer ponto de um processo ou qualquer opção ou aplicativo individual ou de software onde você pode realmente mudar alguma coisa, certo? Isso é o que eles chamam de ponto de controle. E, para mim, é realmente valioso que você obtenha essa estrutura visual. Porque então você pode ver e meio que caminhar e isso leva tempo. Leva tempo para o cérebro humano gerenciar essas coisas e realmente entendê-las e, portanto, otimizá-las, certo?
Ron Huizenga: Absolutamente. E para usar uma analogia diferente que, em minha opinião, coloca em perspectiva: sou um pouco doida pela aviação, então, diria, se você está tentando pensar nisso de maneira paralela, pense em construir um 747 - ou um Airbus 380, por isso não escolho um fornecedor sobre o outro - pense em como seria difícil fazer isso com base em documentos compostos apenas de texto, em vez de plantas e desenhos CAD 3D e tudo de como que é realmente reunido.
Eric Kavanagh: Sim, isso seria difícil. E Jen também precisa falar.
Ron Huizenga: O negócio é o mesmo, certo?
Eric Kavanagh: Sim, não, está certo. Jen precisa falar com uma de suas áreas quentes que você gosta de estudar, que é a visualização. Você tem que ser capaz de visualizar algo para entender completamente, parece-me.
Jen Underwood: Muitos humanos fazem, sim. E mesmo apenas uma visualização fala, qual é o ditado, milhares de palavras ou algo assim. Quando eles vêem, eles podem acreditar. E eles entendem.
Eric Kavanagh: Eu concordo. E eu amo, Ron, o jeito que você meio que juntou tudo isso. Acho que estou me perguntando de novo, você precisa de um campeão dentro da organização e quem estará lá fora, servirá como elo de ligação com diferentes grupos. Os organizadores de dados são algo sobre o qual falamos frequentemente - acho que esse é um papel realmente importante e sinto que esse papel recebeu muito mais atenção nos últimos três ou quatro anos, já que apreciamos o valor dos dados governança, certo? Esse administrador de dados é alguém que pode conversar com os negócios, mas também entender os sistemas, entender o ciclo de vida dos dados, todo esse cenário. E acho que essa pessoa pode e provavelmente deve estar sob o domínio do CEO, certo?
Ron Huizenga: Sim, e você precisará de uma equipe multifuncional, certo? Então, você precisará de pessoas que integrem uma equipe para fazer isso ou que sejam de diferentes áreas, representando o lado técnico, as diferentes áreas de negócios. E, você sabe, dependendo do tipo de organização que você é, se você tem um escritório de gerenciamento de projetos e muitas das iniciativas que você realiza são dirigidas por um PMO, você precisará ter certeza de que possui PMO envolvimento também apenas para manter todo mundo em harmonia e sincronizar a maneira como estão trabalhando nas coisas.
Eric Kavanagh: Sim, e você sabe, uma última coisa, vou colocar este último slide, estrutura de governança. Tivemos uma pergunta do participante, não há dados ausentes nesse slide? Os dados estão implícitos no slide ou o que você acha do comentário sobre a falta de dados no slide?
Jen Underwood: Não, e isso é apenas uma estrutura de governança genérica. Essencialmente, isso é do espaço de BI de autoatendimento, portanto os dados estão implícitos em muito disso. Isso vinha apenas do meu ângulo e das minhas perspectivas, e não tão focado no lado dos dados para montar isso. Mas os dados certamente seriam, quando você pensa em todas essas partes, haveria dados. Seja a base para dados, prestação de contas usando dados durante todo o processo e em toda a estrutura.
Eric Kavanagh: Sim, não, isso faz todo sentido. E acho que vou fazer apenas uma última pergunta para você enquanto terminamos aqui, Ron. Se eu pensar em quanto mais informações e quantos dados estamos usando hoje em dia e quão longe são as organizações, qual é a importância dos ecossistemas atualmente entre os parceiros de canal e como podemos compartilhar informações entre essas parcerias e de uma maneira pouca referência rápida da blockchain a isso - para não complicar as coisas. O ponto principal é que estamos em um mundo conectado cada vez mais orientado a dados, tanto da perspectiva dos negócios quanto apenas de nossas vidas diárias. E para mim, isso só aumentará ainda mais o risco de as organizações darem uma boa olhada no que você está sugerindo aqui, que é a maturidade delas, onde estão e quanto tempo elas estão em termos de curva e realmente sendo honesto consigo mesmo sobre isso, certo? Porque se você não conhece melhor, não pode fazer melhor, e se não refletir sobre as coisas, não saberá melhor, certo?
Ron Huizenga: Exatamente. E acho que uma frase que eu usaria é que você provavelmente não é tão bom quanto pensa. Isso pode parecer meio duro, mas as pessoas podem ser bastante otimistas quanto a isso, mas se você der uma olhada muito dura e uma auto-avaliação crítica muito boa, acho que qualquer organização encontrará, sabe, lacunas significativas que elas precisa abordar.
Eric Kavanagh: Eu tenho que concordar. E um de nossos colegas comentou a importância dos metadados, os dados sobre os dados. Não há dúvida sobre isso. Os metadados são a cola que mantém todos esses sistemas juntos e ainda nunca deciframos totalmente esse código, e por boas razões, francamente, porque os metadados são alterados. É diferente de sistema para sistema. Sabe, quanto mais você tenta normalizar seus dados, menos preciso eu acho que eles se tornam.
Então, estamos nesse mundo estranho agora e talvez eu ache que estenda mais uma pergunta para você, Jen, porque você mencionou catálogos de dados algumas vezes. Eu realmente amo esse novo movimento da tecnologia de catálogo de dados que varre automaticamente seus sistemas de informação, verifica nomes de colunas de metadados e assim por diante, além de ajudá-lo a construir de maneira incremental a visão estratégica de seus dados e metadados em seus sistemas. Porque para mim, fazer manualmente essas coisas, é apenas, é demais. E você nunca vai chegar ao topo daquela colina antes que a avalanche caia sobre você e, você sabe, ou você se normalizou ao ponto da massa de brincar ou não se normalizou o suficiente para onde realmente não sei o que está acontecendo. To me, using the machines, the machine learning that we keep talking about, that's going to be the key in the future to help us at least get a rope around enough of the data to have a good understanding of what's out there, right Jen?
Jen Underwood: Yeah, I do. I love these technologies. They're very, very cool. And then you think about it, it gives you that massive running start. And then you can crowdsource. You have your data stewards, you know, pulling ahead, whether they're adding their own documentation or this is the perspective out there, these are the changes. You know, saying these are the certified data sources to use for reporting. People can search and find the right data. It's really, really quite nice. And also helps to – when I think about business and how cryptic enterprise data management was when I was when I was doing DBA stuff – we used extended properties and SQL Server and scan with tools like IDERA's, right? To try to create a data catalog. But in DBA or data architects' version of, you know, whatever that value was or that column or field was, it certainly probably didn't match what the business was. So now having the business be able to really easily, you know, go in and find and manage and have everything be goal-based, it's really, I wish we would've had this a long time ago, quite frankly. So it's getting a lot better.
Eric Kavanagh: Isso é engraçado. We've got another final comment from an audience member, saying perhaps blockchain will be the most valuable to put a stamp of authentication to metadata. That's a good point and, you know, blockchain really is amazing technology. I kind of view it as a sort of cohesive foundation for connecting a lot of the dots between systems and applications and so forth. And, you know, we're in the early stages of blockchain development, but we now see that it is spun off, of course, from this point originally where it came to the fore, and now you've got IBM working very hard on blockchain technologies. SAP has bought into all that. And really it's, it presents an opportunity for a deeper foundation and framework to connect all these systems and all these dots.
So, folks, have burned well over an hour. Thanks for staying along with us today, but we always like to answer your questions and get to all the commentary. We do archive all these webcasts for later viewing, so hop online to insideanalysis.com, where you can find the link to that. It should be up within a few hours, typically after the event. And we'll catch up to you next time. We got a couple more events coming up next week – lots of stuff going on. But that will bid you farewell, folks. Obrigado pelo seu tempo. Cuidar. Tchau tchau.
