My understanding of why System Thinking is useful + first round of Target system Reveal

Why we having projects? building/supporting/changing the systems? - to make life better!

What is better? better is when all external project roles are satisfied! there are three key words/concepts here: BETTER for ALL EXTERNAL_PROJECT_ROLES

  1. BETTER
    1. each EXTERNAL_PROJECT_ROLE have interests and concerns. So to be able to make BETTER, we need to map them all, find contradictions and find quasi-optimal solution (as very little chances to find really optimal solution for all! - it's and evolution rule)
    2. in my case:
      • Plant Maintenance manager wants to buy a spare part for their conveyor. And it will be easier and faster just to create new Spare part code and launch the Procurement process
      • Finances controller wants to track all new Spare parts creation to avoid duplicates. As it may prevent them to find a Vendor for several plants together and launch the procurement process with the much stronger position (bigger buying lot - more chances for discount).
      • Regional Maintenance manager wants to be able to check if the same spare part is available in another plant and just can be used not bought
  2. ALL
    1. to achieve it you need to identify not only your system but the target system, and the chain of all enabling systems. As otherwise your changes will impact
    2. In my case -
      • My System is Master Data Governance Department in enterprise
      • Master Data Governance is ensuring that Master Data is created and used across organization in agreed way to support all needs across entire enterprise (Sales, Manufacturing, Procurement) avoid duplications and inconsistencies.
      • Master Data is data about the business entities that provide context for business transaction (like: Products, Vendors, Customers, Materials).
      • Business transactions are buy a Material from a Vendor, convert Material into Product, Transport the Product to the Customer and sell it,
      • Data also is an object for IT department (how to model it, store, use, report...)
      • Data is also an asset for Enterprise - meaning very careful attention of Finance and Internal control for risks and legislation requirements (see Sarbanes–Oxley Act - Wikipedia)

All the above is useless until the Product reach end customer and (s)he pays for that - so this I believe is a Target System = End Customer enjoys Payed Product

3. EXTERNAL_PROJECT_ROLES usually in my company it’s usual to consider those who are directly impacted by the project: end users, their managers and big boss who is paying for this. But as saying goes “there are minimum 15 EXTERNAL_PROJECT_ROLES and always +1 to what you have identified. Those whom you forgot will come to you when system is ready and will make your life brighter and much vibrant with their unconsidered by you concerns and interests..” So watch out here!

Not target system, system-of-interest. External project roles – stakeholders. Not system reveal, but better system discovering (rare), even more better will be system definition (standard name for it).

Department is organizational unit (constructive object, not functional object, not orgrole), you need something functional for system definition. Data are descriptions, not systems. We will explore this case at a group meeting.

Осмысленное деление видов данных такое:
– справочные данные: картина мира, как он устроен везде – учебники, классификаторы, справочники, стандарты, законы, upper и middle ontology и т.д… В общем, НСИ (нормативно-справочная информация) в ассортименте, правила и ограничения живут тут. Можно различать знания (неформализованная информация) и данные (структурированная информация, базы данных и графы знаний). И тут особо выделяются мастер-данные: это данные НСИ, подвластные одному центру администрирования. “Собственность” тут пролезает неявно, как в “системах систем”.
– конфигурационные и версионные данные, описания разных систем as designed: функциональное и конструктивное знание о целевой системе и её окружении и создающих системах (это и есть проект/design целевой системы и организационная часть от project – то бишь organizational design системы создания).
– трансакционные данные: данные об изменениях (временные ряды в ходе operations, первичка для внесения изменений в конфигурацию design, в том числе обеспечивающие системы и системы в операционном окружении). Это, по большому счёту, информация разных сообщений. Тут особо выделяются “ряды”, “исторические данные”, “логи” как то, с чем работают digital twins (модели времени эксплуатации, причём как целевой системы, так и систем создания).

Но это всё данные. Искать нужно а) системы, с ними работающие/их интерпретирующие и б) что именно описывают эти данные, что мы собираемся менять (изменение этих данных нам нужно для изменения чего? вот ключевой вопрос).

Thanks for the post!
I have some experience in constructing knowledge-graph-powered MDM systems for oil and gas industry as a software engineer, but it is hard to believe there are different departments for MDM and IT in your enterprise.

Hi Nikolay, indeed MDM and IT are part of bigger Digital department, but they have different interests and concerns (MDM is looking after “content” and IT - after “container” if I may say) - that’s why I separated them