Le data lineage et l’usage des données pour transformer un système : simplifications / migrations

I- Introduction  _______________________________________ Courte histoire de SAP BO :  La Business Intelligence existe depuis 30-40 ans. Business Object, vient de souffler ses 30 bougies (1990). Pratiquement aux origines ! L’idée géniale des inventeurs :  rendre intelligible la donnée, et la mettre à portée de clic pour le métier.           Au départ, dans chaque entreprise qui implémente SAP BO, il y peu d’utilisateurs, mais très vite les plateformes sont dépassées par leur succès. Des Business Analysts viennent s’interfacer. La complexité, et même l’hyper complexité deviennent la norme. Et la confiance s’étiole. Les versions (BO 3.0…. 6, XI, XI R3, 4.0,1,2,3 …) se sont enchainées sur quasi 30 ans sans véritablement bouleverser le concept de départ même si la version Cloud (SAP Analytics Cloud) vient de voir le jour.    SAP BO vs « les tendances de marchés » : Le métier veut de l’autonomie, veut pouvoir jouer dans d’immenses « bacs à sable » de données, et obtenir des réponses instanta

  I-Introduction  _______________________________________ Short History of SAP BO:  Business Intelligence has existed for 30-40 years.  Business Object, has just celebrated its 30th anniversary (1990).  Practically at the origins! The inventors' brilliant idea: make the data intelligible, and put it within a click of a button for the profession.           Initially, in each company that implements SAP BO, there are few users, but very quickly the platforms are overwhelmed by their success.  Business Analysts come to interface.  Complexity, and even hyper complexity, are becoming the norm.  And confidence is fading. The versions (BO 3.0…. 6, XI, the day.    SAP BO vs “market trends”: The profession wants autonomy, wants to be able to play in immense “sandboxes” of data, and obtain instantaneous and reliable answers.  We have entered the era of data viz, self-service BI...etc.   For some time now, the Cloud has been sweeping away everything in its path with promises of scalability, l

  Comment savoir que votre dette technique IT est un problème ? Vos coûts de maintenance des systèmes augmentent-ils ? Trouvez-vous difficile d'embaucher des personnes pour travailler sur votre projet ? Est-ce qu’il y a d'ailleurs encore des gens qui maitrisent les technos qui vous posent problème 😊 ? La modification à la marge du projet sur lequel vous travaillez prend-elle beaucoup plus de temps qu'il y a un an ? …. Si les réponses sont positives, cela pourrait signifier que la dette technique IT de votre organisation augmente et finit par obérer l’agilité de votre entreprise. Les recherches de Stripe suggèrent que "le développeur moyen passe plus de 17 heures par semaine à traiter des problèmes de maintenance, à gérer la "dette technique IT ". Inquiétant ! Pourquoi parle-t-on de « dette » technique IT ? La dette technique fonctionne de la même manière que la dette financière. Si le prêt n’est pas remboursé, les mensualités ou les annuités s’empilent augme

  How do you know your IT technical debt is a problem? Are your system maintenance costs increasing? Do you find it difficult to hire people to work on your project?  Are there still people who master the technologies that are causing you problems 😊? Is it taking much longer to make marginal changes to the project you're working on than it did a year ago? …. If the answers are positive, it could mean that your organization's IT technical debt is increasing and ultimately hampering your business agility. Stripe's research suggests that "the average developer spends more than 17 hours per week dealing with maintenance issues, managing 'IT technical debt.'" Worrying! Why do we talk about IT technical “debt”? Technical debt works the same way as financial debt.  If the loan is not repaid, the monthly payments or annuities pile up plus interest, and the amount to be repaid ends up being much higher than the initial amount of the loan.  The longer you ignore te