Conseil 72: décoder les processus métiers

Dans le conseil 69, l'identification des processus métiers, l'auteur discutait de l'importance de reconnaître les processus métiers de votre organisation et fournissait des lignes directrices pour les repérer. Nous plongeons dans plus de détails ici.

Mettre l'accent sur les processus métiers est absolument essentiel pour mettre en œuvre avec succès une solution d'entrepôt de données à l'aide de la méthode Kimball. Les processus métiers sont la pierre angulaire d'un entrepôt de données dimensionnel. Nous vous proposons de construire votre entrepôt de données de manière itérative, un processus à la fois. Vous pouvez vous demander , " Qu'y a-t-il de si magique avec les processus métiers? Comment l'identification des processus métiers nous aide dans nos activités de modélisation dimensionnelle?". La réponse est que l'identification correcte des processus métiers lance toute la conception dimensionnelle. Le secret est que chaque processus se traduira par au moins une table de fait. En résumé, l'identification des processus métiers permet d'identifier les tables de faits à construire.

Conseil 71: le nommage des champs

La question de la dénomination des champs se pose lorsque vous créez le modèle de données dimensionnel. Le nommage est complexe parce que les gens ont des significations différentes pour un même nom, comme "chiffre d'affaire", et des noms différents avec le même sens, comme "ventes". La difficulté vient de la nature humaine: la plupart d'entre nous ne voulont pas renoncer à ce que nous savons pour apprendre une nouvelle façon. La tâche peu enviable de déterminer les noms tombe généralement sur le gestionnaire des données. Si vous êtes responsable de cette tâche, vous trouverez l'approche suivante en trois étapes utile. Les étapes 1 et 2 se produisent généralement avant que le modèle soit présenté aux utilisateurs métiers. L'étape 3 arrive généralement après que les utilisateurs métiers aient vu et compris le modèle.

Conseil 69: Identifier les processus métiers

Les lecteurs qui suivent l'approche de Kimball peuvent souvent réciter les quatre décisions clés de la conception d'un modèle dimensionnel: identifier le processus métier, la granularité, les dimensions et les faits. Bien que cela semble simple, les équipes butent souvent sur ​​la première étape. Ils peinent à définir le processus métier, car c'est un terme qui semble prendre un sens différent selon le contexte. Puisque l'identification du processus métier est le premier point de la conception d'un modèle dimensionnel, nous voulons éliminer la confusion dans notre contexte.

Tout d'abord, nous allons commencer par discuter de qu'un processus métier n'est pas. Lors de la conception d'un modèle dimensionnel, le processus métier ne se réfère pas à une direction de l'organisation ou à une fonction. De même, il ne doit pas faire référence à un seul rapport ou à une analyse spécifique.

Pour un concepteur décisionnel, le processus métier est un événement ou une activité qui génère ou recueille des métriques. Ces mesures sont des mesures de performance pour l'organisation. Les analystes d'affaires veulent les examiner et les évaluer selon une combinaison illimitée de filtres et de contraintes. En tant que concepteur, il est de notre devoir de présenter ces mesures dans une structure facile à comprendre qui répond rapidement aux demandes imprévisibles.

Lors de l'identification du processus métier pour la modélisation dimensionnelle, des caractéristiques et des tendances communes émergent souvent.

1. Les processus métiers sont généralement pris en charge par un système opérationnel. Par exemple, le processus de facturation de l'entreprise est soutenue par un système de facturation; de même pour les processus achats, commandes, ou reception.
2. Les processus métiers génèrent ou recueillent des mesures uniques avec une granularité et une dimensionnalité unique utilisées pour évaluer la performance de l'organisation. Parfois, les mesures sont le résultat direct du processus métier. D'autres fois, les mesures en sont dérivées. Peu importe, les processus métiers fournissent des indicateurs de performance utilisés par divers procédés analytiques. Par exemple, le processus de gestion des commandes de vente entraine de nombreux rapports et analyses, telles que l'analyse de la clientèle, la performance des commerciaux, et ainsi de suite.
3. Les processus métiers sont souvent exprimés comme des verbes d'action avec les dimensions associées comme des noms décrivant le qui, quoi, où, quand, pourquoi et comment liées au processus. Par exemple, les résultats du processus de facturation de l'entreprise seront découpés et analysés par date, client, service/produit, et ainsi de suite.
4. Les processus métiers sont généralement déclenchés par une entrée et produisent un résultat en sortie qui doit être surveillé. Par exemple, une proposition acceptée est entrée dans le processus de commande qui se traduit par un bon de commande et ses paramètres associés. Dans ce scénario, le processus métier est la commande de vente. Vous aurez donc une table de faits des commandes avec la commande client comme dimension - potentiellement dégénérée - et les montants et le nombre de commande comme faits. Essayez d'imaginer le flux général d'entrée d'un processus métier, et créant des métriques en sortie. Dans la plupart des organisations, il existe un ensemble de processus métiers où les résultats de l'un deviennent les entrées d'un autre. Dans le langage d'un concepteur décisionnel, ces processus métiers se traduiront par une série de tables de faits.
5. Les analystes veulent parfois croiser les processus métiers, comparant ainsi le résultat d'un processus à celui d'un autre. Croiser les processus est certainement réalisable si les dimensions communes aux deux processus sont conformes .

Déterminer les processus métiers de base de votre organisation est essentielle pour établir le cadre global de vos modèles dimensionnels. La meilleure façon de déterminer ces processus est d'être à l'écoute des utilisateurs. Quels sont les processus qui génèrent les indicateurs de performance les plus intéressants pour suivre l'activité? Dans le même temps, l'équipe de l'entrepôt de données doit évaluer les réalités de l'environnement source pour fournir les données convoitées par l'entreprise.

Un dernier commentaire ... Il va sans dire qu'un tableau de bord n'est pas un processus métier, il présente seulement les résultats de la performance de nombreux processus métiers différents.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #69: Identifying business processes", publié le 5 juillet 2005.

Conseil 68: Forer latéralement dans les données avec SQL

Le forage latéral fait réfèrence au processus qui interroge plusieurs tables de faits et en combine les résultats dans un ensemble de données unique. Un exemple courant consiste à combiner les données prévisionnelles avec des données réelles. Les données prévisionnelles sont généralement conservées dans une table séparée, capturé à un niveau de détail différent de celui des données réelles. Quand un utilisateur veut un rapport qui compare le réel et le prévisionnel par client, la requête doit mixer deux tables de faits. (Note: les données des deux tables de faits peuvent être combinées uniquement si elles sont construites en utilisant des dimensions conformes. Le client, la date et toutes autres dimensions partagées doivent être exactement les mêmes dans les deux schémas en étoile).

Le moyen le plus efficace de combiner les données des deux tables de fait est d'exécuter des requêtes distinctes sur chaque table, puis de combiner les deux ensembles de résultats en faisant correspondre leurs attributs communs. Cette solution focntionne bien car la plupart des optimiseurs de base de données reconnaissent chaque requête unique et retournent rapidement les deux ensembles de résultats.

Conseil 67: Maintenir des références vers les sources opérationnelles

Nos entrepôts de données sont de plus en plus orientés vers le suivi des opérations détaillées des clients en quasi temps réel. Et comme Patricia Seybold souligne dans son livre, Customers.com (Times Business, 1998), la gestion des relations client, c'est avoir accès aux données de tous les processus d'une organisation en relation avec les clients.

Garder les informations détaillées issues de tous les processus faisant face aux clients, et en même temps fournir une vision intégrée, présente un défi intéressant pour l'architecte ETL. Supposons que nous ayons une entreprise orientée client avec une quinzaine de systèmes en relation avec celui-ci comme la gestion des ventes des magasins, des ventes en ligne, des livraisons, des paiements, des crédits, des contrats de maintenance, des centres d'appels et diverses formes de communications commerciales. Beaucoup de ces systèmes créent leur propre clé naturelle pour chaque client, et certains d'entre eux ne traitent pas les doublons se référant à un même client. Au final, Il se peut que nous n'ayons aucun identifiant client unique et fiable à travers tous ces systèmes.

Conseil 66: Répondre à la paralysie de l'analyse

De nombreuses équipes en charge de l'entrepôt de données penchent fortement vers le côté pratique. Ils passent rapidement à la mise en œuvre sans passer assez de temps et d'énergie à développer leurs modèles de données, à identifier minutieusement les règles métiers, ou à planifier leurs processus de réconciliation des données. Par conséquent, ils chargent à toute vitesse et finissent par revoir leurs processus, fournissant au passage des données incorrectes ou incomplètes, et entraînant généralement des difficultés.

D'autres équipes ont le défi inverse. Ces équipes se sont engagées à faire leurs devoirs dans tous les domaines critiques. Ils sont concentrés sur la qualité des données, la cohérence, l'exhaustivité et l'administration. Cependant, ces équipes s'enlisent parfois dans des problèmes qui auraient dû être résolus depuis longtemps. Bien sûr, cette impasse se produit au pire moment - les dates de mise en œuvre promises approchent rapidement et les décisions de conception qui devaient être prisent lors de la mise en œuvre restent en suspens.

Conseil 65: Documentez votre système ETL

Que vous utilisiez un outil ETL ou codiez à la main votre système d'ETL, celui-ci est un logiciel comme les autres qui doit être documenté. De même que votre entrepôt de données évolue, le système ETL évolue également, et vous et vos collègues devez être en mesure de comprendre rapidement l'ensemble de l'architecture du système ainsi que ses petits détails.

Il ya un mythe répandu affirmant que les outils ETL sont auto-documentés. Ceci n'est vrai que pour la comparaison avec les systèmes développés manuellement. N'adhérez pas à ce mythe: vous avez besoin de développer une architecture globale et cohérente pour votre système ETL. Et vous devez documenter ce système. Oui , rédiger un document.

Conseil 64: Eviter l'isolation entre les équipes décisionnelles

Peut-être est-ce juste une coïncidence, mais plusieurs personnes ont posé la même question récemment: "Est ce que l'équipe décisionnelle devrait récolter les exigences des métiers?" Honnêtement, cette question me fait froid dans le dos. Je crains que beaucoup d'organisations aient trop compartimentées leurs équipes décisionnelles et celles en charge de l'entrepôt de données.

Conseil 63: Construire un système qui capte les changements de données

Le flux de données ETL commence par transférer les données les plus récentes de la source dans l'entrepôt de données. Dans presque tous les entrepôts de données, nous devons transférer que les modifications pertinentes de la source de données depuis le dernier transfert. Rafraichir complètement nos tables de faits et nos dimensions est généralement inopportun.

L'activité d'isoler les dernières données de la source s'appelle "la capture de données". L'idée derrière cela semble assez simple: il suffit de transférer les données qui ont été modifiées depuis le dernier chargement. Mais la construction d'un bon système de capture de données n'est pas aussi facile qu'il n'y paraît.

Conseil 62: Hiérarchies alternatives

De nombreux utilisateurs demandent souvent à voir des données groupées de différentes façons. Dans le cas le plus simple, un service, comme le marketing, veut voir les clients regroupés selon une hiérarchie donnée et un autre service, comme le commercial, veut les voir dans une hiérarchie différente. Lorsque c'est simple, il est logique d'inclure les deux hiérarchies dans la dimension Client et de les nommer distinctement. Malheureusement, il est possible de construire de nombreuses hiérarchies dans une dimension avant que cela  ne devienne inutilisable.

La nécessité d'adapter de manière plus souple les hiérarchies alternatives se produit donc lorsque plusieurs services veulent voir les choses à leur façon, et veulent voir cela de plusieurs manières. Dans ce cas, nous travaillons généralement avec les utilisateurs pour définir le moyen le plus courant de regrouper les données. Cela devient ensuite la norme ou la hiérarchie par défaut dans la dimension de base. Toutes les autres hiérarchies couramment utilisées sont également intégrées dans la dimension afin de simplifier le travail des utilisateurs.

Nous proposons ensuite une table de hiérarchie alternative qui permet aux utilisateurs de manipuler les données en fonction de leur choix et des hiérarchies alternatives disponibles. La figure ci-dessous montre un exemple d'une table intermédiaire de hiérarchie alternative appelée CustomerRegionHierarchy pour aligner les régions géographiques.

Chaque hiérarchie de la table des hiérarchies alternatives doit inclure toute la hiérarchie de son attribut le plus fin, qui sert de jointure avec la dimension associée, à celui le plus haut. Dans le cas illustré ici, la hiérarchie commence au niveau de l'état (State) et remonte à partir de ce point. Il est également possible de commencer à un niveau de détail plus fin, le code postal par exemple, mais cela rendrait la table intermédiaire plus grosse et n'apporterait pas d'avantages supplémentaires. D'un autre coté, s'il y a besoin de créer des groupes de codes postaux dans les états, la table hiérarchique intermédiaire doit évidemment commencer au niveau du code postal.

Pour simplifier les rapports et analyses, la table intermédiaire inclue la définition de la hiérarchie standard. Ce choix devient alors celui par défaut dans tous les rapports structurés, permettant aux utilisateurs de changer ensuite entre la hiérarchie standard et les hiérarchies alternatives. La création d'une table Hiérarchie séparée simplifie la maintenance en ayant une ligne par hiérarchie, mais accroit la complexité visuelle. Cette table peut également être dénormalisée dans la table intermédiaire.

La table CustomerRegionHierarchy peut être utilisée dans les rapports structurés ou par les utilisateurs avancés. La jointure avec la table Client entrainera des cumuls inexacts à moins que le champ HierarchyName soit filtré sur une hiérarchie unique. Tous les rapports structurés qui ont accès à la table des hiérarchies alternatives peuvent être construit en utilisant la hiérarchie par défaut et devraient posséder un filtre choisir une seule hiérarchie.

La table des hiérarchies alternatives est un exemple de valeur ajoutée dans un entrepôt de données. Ce genre de regroupement personnalisé est couramment utilisé par les métiers, mais les définitions sont rarement centralisées et gérées de manière formelle. Habituellement, elles sont stockées dans un fichier Excel sur un ordinateur personnel.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #62: Alternate hierarchies", publié le 7 décembre 2004.

Conseil 61: Traiter toutes les dates

Il n'est pas exceptionnel d'identifier des douzaines de dates différentes, chacune ayant un sens métier qui doit être pris en compte dans la conception dimensionnelle. Par exemple, dans un établissement financier, vous pouvez avoir affaire à la date de dépôt, la date de retrait, la date de financement, consulter la date d'écriture, la date de traitement, la date d'ouverture de compte, la date de validité d'une carte, la date de lancement d'un produit, la date de début d'une promotion, la date de naissance d'un client, une plage de dates pour les chargements et l'état du mois.

La première chose à savoir est que toutes les dates ne sont pas créées et traitées de la même manière. Beaucoup de dates finissent comme clés étrangères de la dimension Date dans les tables de faits. La plupart des dates restantes deviennent des attributs d'autres dimensions. Enfin, certaines dates sont inclues dans la conception pour faciliter le traitement ETL et/ou les capacités d'audit.

Conseil 59: Le profilage de données (ou data profiling)

Le profilage de données est une petite partie de l'entrepôt de données. Je suppose que la plupart d'entre nous pensent que c'est une tâche qui se fait après que les traitements ETL aient été construit. De ce point de vue, le profilage des données correspond à la recherche des petites anomalies présentes dans les données et qui pourraient être corrigées avant la production réelle de celles-ci. Trouver ces anomalies aiderait l'équipe décisionnelle à anticiper quelques surprises en production.

Durant l'année passée, j'ai longuement réfléchit aux processus ETL d'administration nécessaires pour construire un entrepôt de données. Peut être la plus grande révélation de ce travail fut de découvrir combien le profilage des données est sous estimé dans la majorité des projets décisionnels.

Qu'est ce que le profilage de données?

Conseil 58: Le portail décisionnel

Le succès d'un système décisionnel dépend de la capacité qu'a l'organisation a en tirer de la valeur. De toute évidence, les gens doivent utiliser l'environnement pour que l'organisation puisse créer de la valeur. Puisque le portail décisionnel est le principal point d'interaction (le seul dans de nombreux cas), l'équipe décisionnelle doit veiller à ce que ca soit une expérience positive.

Trop souvent, la page d'accueil du portail décisionnel se concentre en grande partie sur l'historique de l'entrepôt de données, l'état actuel des processus de chargement, ou les membres de l'équipe décisionnelle. Ce sont des renseignements intéressants, mais généralement ce n'est pas ce que les utilisateurs recherchent. Le portail décisionnel est l'interface entre l'utilisateur et l'entrepôt de données. Il doit être conçu en fonction des besoins des utilisateurs avant tout. Il y existe deux concepts de base pour la conception de sites Web qui peuvent nous aider: la densité et la structure.

Densité

L'esprit humain peut recevoir une quantité incroyable d'informations. L'œil humain est capable de distinguer des images d'une résolution d'environ 530 pixels par pouce à une distance de 20 pouces (RN Clark). Comparez cela avec les pauvres 72 pixels par pouce des écrans d'ordinateurs classiques. Nos cerveaux traitent l'information rapidement à la recherche d'éléments pertinents. Cette combinaison de l'acuité visuelle et de la capacité mentale est ce qui a permis à nos ancêtres de se sortir des différentes menaces; des prédateurs pour les branches basses à un couteau dans une bagarre dans un bar. Le navigateur nous donne une telle plate-forme basse résolution que nous devons l'utiliser avec autant de soin et efficacement que possible. Cela signifie que nous devons remplir les pages du portail décisionnel avec le plus d'informations possible. Mais nous ne pouvons pas charger des centaines de descriptions et de liens désordonnés.

Structure

Notre cerveau peut saisir toutes ces informations que si elles sont organisées. Puisque la principale raison qui pousse les utilisateurs à venir sur ​​le portail décisionnel est de trouver des informations, un grand pourcentage de la page d'accueil devrait être consacré à la catégorisation des rapports et analyses standardisés d'une manière qui fait sens pour les gens. Généralement, nous trouvons que la meilleure organisation du portail décisionnel est autour des principaux processus métiers de l'organisation. Les catégories de processus métier permettent aux utilisateurs d'identifier rapidement le choix le plus pertinent. Dans chaque catégorie, il existe des sous-catégories, permettant à l'utilisateur d'analyser rapidement la page d'accueil pour trouver de l'information qui l'intéresse.

Par exemple, la page d'accueil du portail décisionnel d'une université pourrait contenir les catégories suivantes:

Admissions                       Employés                                           Finances

Anciens élèves                  Recrutement                                       Recherche

Chacun de ces liens renvoit vers une autre page qui fournit des éléments supplémentaires et des liens vers les rapports. Nous pouvons augmenter la densité de l'information en plaçant les sous catégories sur la page d'accueil:

Admissions                              Suivi des employés                              Recrutement

- Statistiques                            - Effectifs                                            - Inscription

- Offres et acceptation              - Avantages et vacances                     - Professeurs

- Aide financière                       -                                                        - Diplômes

Augmenter de la densité de cette manière permet de détailler chaque catégorie et d'affiner le choix de l'utilisateur avant qu'il clique. Une façon de tester votre page d'accueil est de mesurer le pourcentage de la page qui est visible (avec un navigateur en plein écran sur un écran de taille moyenne) et qui permet aux utilisateurs d'accèder à l'information. Il doit être d'au moins 50%. Certaines personnes affirment que la cible devrait être plus proche de 90%.

Plus de structure

Les catégories aident à structurer le contenu, mais le site web a également besoin d'être organisé correctement. Il a donc besoin d'un design standard, normalement basé sur la charte visuelle de l'organisation afin que les utilisateurs puissent naviguer facilement.

Plus de contenu

Bien que l'objectif premier du portail décisionnel est de fournir un accès aux rapports, il doit également montrer plus d'information. En plus des catégories et de la liste des rapports, nous avons besoin de fournir un accès à un ensemble d'outils et d'informations comprenant:

- un outil de recherche qui indexe chaque rapport, document et page du portail

- un navigateur de métadonnées

- une formation en ligne, des tutoriels, des exemples de rapports, une aide

- un formulaire de demande d'aide, et une liste de contacts

- les statuts, guides, sondages, installations et autres informations administratives

- peut être un outil de type forum, d'échange en ligne

- des fonctionnalités de personnalisation qui permettent aux utilisateurs de sauvegarder des rapports ou des liens vers ceux-ci dans leur propre page

Cette information se place en bas à droite de la page, l'endroit le moins important de l'écran.

Construire un portail décisionnel efficace représente une somme importante de travail, mais c'est le maillon clé dans la chaine de valeur de l'entrepôt de données. Chaque mot, entête, description, fonction et lien de ce portail doit pointer vers le contenu de l'entrepôt. Vous devriez passer en revue la conception et tester le portail avec les utilisateurs, demandez leur de trouver certains rapports et d'autres informations. Assurez-vous que vous ne construisez pas de lien bizarre.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #58: The BI portal (also known as the data warehouse web site", publié le 26 août 2004.

Conseil 57: Traiter les faits qui arrivent en avance

Les entrepôts de données sont généralement construits autour de l'hypothèse idéale que l'activité mesurée (les enregistrements des faits) arrive dans l'entrepôt de données en même temps que le contexte qui lui est associé (les enregistrements des dimensions). Lorsque nous avons à la fois les enregistrements des faits et ceux des dimensions corrects, nous avons le luxe de comptabiliser les clés de la dimension en premier, puis d'utiliser celles-ci dans les enregistrements de la table de faits qui l'accompagne.

Fondamentalement, trois choses peuvent se produire quand nous comptabilisons les enregistrements de la dimension.

1. Si l'entité de la dimension (par exemple Client) est un nouveau membre de la dimension, nous attribuons une nouvelle clé de substitution dans la dimension.
2. Si l'entité de la dimension est une version révisée d'un client, nous utilisons la technique de la dimension à évolution lente de type 2 pour attribuer une nouvelle clé de substitution et stocker la description du client qui a été mis à jour dans un nouvel enregistrement de la dimension.
3. Enfin, si le client est un élément familier et inchangé de la dimension, nous utilisons simplement la clé de la dimension que nous avons déjà pour ce client.

Conseil 55: Explorer des faits textuels

Dans cet article, nous revenons sur un concept fondamental qui déconcerte de nombreux modélisateurs décisionnels: les faits de type texte.

Certains d'entre vous observerons à juste titre que les faits de type texte sont un oxymore de la modélisation décisionnelle. Toutefois, nous avons souvent à répondre aux questions de clients et d'étudiants sur des champs indicateur, type ou commentaire qui semblent appartenir à la table de faits, mais dont les valeurs ne sont pas assimilées à des clés, des mesures ou des dimensions dégénérées.

Conseil 54: Fournir la vue courante et la vue historique d'une dimension

Comme la plupart des choses dans la vie, le changement est inévitable, même avec les attributs des dimensions. La plupart de nos lecteurs sont familiers avec les trois techniques de dimension à évolution lente (SCD):

• Type 1: Remplacement d'attribut 
• Type 2: Ajout d'une autre ligne dans la dimension 
• Type 3: Ajout d'un autre attribut dans la dimension

Quand des attributs de dimensions changent, nous sommes souvent sollicités pour conserver leurs valeurs précédentes, ainsi que pour fournir la possibilité de croiser les faits historiques avec les valeurs courantes des attributs. La demande pour cette aptitude augmente au fur et à mesure que les utilisateurs mûrissent leurs analyses. Il y a vingt ans, les analystes étaient satisfaits d'avoir des tables de dimensions qui étaient rafraîchies (écrasé) avec les valeurs d'attributs courantes à chaque chargement. Puis le mouvement c'est inversé pour capturer avec précision tous les changements en utilisant les dimensions à évolution lente de type 2. Maintenant, plus de gens veulent avoir le beurre et l'argent du beurre.

Conseil 53: Embellissement de dimension (mini-dimension et agrégation)

Lors du développement de modèles dimensionnels, nous nous efforçons de créer des tables de dimensions solides composées d'un ensemble d'attributs descriptifs. Plus les attributs que nous intégrons dans ces dimensions sont pertinents, plus les utilisateurs sont capables d'évaluer leurs activités par des voies nouvelles et créatives. Cela est particulièrement vrai lors de la construction d'une dimension centrée sur le client.

Nous vous encourageons à intégrer le capital intellectuel dans les modèles dimensionnels. Plutôt que d'appliquer des règles métiers aux données au niveau de l'analyse (souvent en utilisant Excel), les dérivations et les regroupements nécessaires par l'entreprise doivent être capturés dans les données pour qu'elles soient cohérentes et facilement partagées entre les analystes indépendamment de leurs outils. Bien sûr, cela nécessite de comprendre ce que l'entreprise fait avec les données avant et après leurs capture dans la source opérationnelle. Cependant, c'est grâce à cette compréhension et l'ajout d'attributs dérivés (et de mesures) que l'entrepôt de données apporte une valeur ajoutée.

Conseil 52: Améliorons nous procédures opérationnelles

Dans ma carrière, j'ai été en mesure d'examiner un grand nombre d'entrepôts de données, à différents stades de leur cycle de vie. J'ai observé que, de façon générale, nous n'avions pas la même rigueur dans le fonctionnement du système d'entrepôt de données que les personnes en charge du système transactionnel peuvent attendre de leurs systèmes. En toute équité, un entrepôt de données n'est pas un système transactionnel, et peu d'entreprises peuvent justifier un contrat de service 24x7 pour l'accès à l'entrepôt de données. Mais Allez les gars, faut-il ressembler à des chiens fous en cas d'urgence? Comme nous le savons tous, les problèmes arrivent - surtout lorsqu'un entrepôt de données est en aval de tout autre système dans votre entreprise.

Exploiter un entrepôt de données de manière professionnelle n'est pas si différent des autres systèmes: Suivre les bonnes pratiques, prévoir les catastrophes, et s'entraîner. Voici quelques suggestions simples, basées sur mes observations des déploiements actuels.