系统的学习Data & Analytics

hxsh2000

Pippa 发表于 2022-9-11 21:40
我分享出来也是这个意思：大企业很难真正实现中央数据平台，因为资源很难满足需求。这个需求除了是做出怎 ...

一个非科技类的比较传统的公司，CXO等能够进入Senior Executive Leadership team的机会都非常非常之难得和有限。很多部门的General Manager甚至子公司的CEO们，终其一生在这些职位上面努力了几十年，都没有能混入到SLT中。现在数据分析团队的新老板Chief Data Officer，经常一步登天，直接成为与CFO, CIO并行的SLT中的一员，四十几岁左右就有机会进入到最核心的高管团队中，几年的时间是值得的。我看到的就是，IT, Strategy, Commercial的很多高管，都在抢着拿到CDO这个机会进SLT

我的理解是，你可能不在这个领域中，所以在这块方面，更多的还是以观察者看到发生的一面。而数据分析这块战略与执行，很多时候是一波一波的，也很多时候是大佬们敲定了，在战略层面敲定了后，才放下来让觉得可以做的人来执行。如果没弄好，那么就hold一段时间，从之前的经验学习并且意识到需要更多的资源和技能才能做好，接着再发起另一波，继续做。

最近在看一本书《Fail Fast, Learn Faster: Lessons in Data-Driven Leadership in an Age of Disruption, Big Data, and AI》

hxsh2000

Pippa 发表于 2022-9-11 21:47
可能跟楼主的行业差别有点大。我们行业的数据与其说是资产还不如说是工具，因为并没有营销的需要。我个人 ...

我还是想说一点，使用已有的思考方式来看待数据以及分析，很容易得出相似的结论。数据和分析解决的关于战略和执行方面的需求，也并不一样。就如我经常性的问公司各个部门的头头，数据和分析团队能为你们做什么，你们需要什么，现在掌握的数据点阵，能够支持我们未来的管理和公司的业务战略吗？得到的答案，非常像你说的，就是现在的数据是比较足够的，挑战是数据没有整合的很好，开发速度太慢，数据的连续性并不太好。

然而事实却是如此吗？当我去问CXO们这些问题时，得到的答案却非常相反。在CXO们的视角来说，我们并不特别清楚我们需要什么，是否有足够的数据支撑我们未来的业务战略和策略执行，并没有信心；我们对于有什么数据，哪些重要哪些不重要也不明确。所以公司最高层这个层面上，参与进这个层次和级别的SLT成员，对于这块的战略和想法，是非常急迫和清晰的。可主要问题就是，最上层知道要什么，却需要各个部门的头头们去理解和具体化各个方面的计划而执行，然而公司内部却很难找到跳脱出已有框架的，能够理解这些对于未来来说，并不确定的比较概念性的也并不具体的构想。其实这些才是公司最高层的pain point

hxsh2000

其次，沟通的基础是什么？是根据对方不同的层级，不同的风格，不同的背景，都需要有不同的沟通策略，而基础就是要去熟悉和了解这些信息。

很多时候，下属会由于自我的层级和眼界的限制，或者缺乏仔细的观察意识，了解不了太多的信息，于是使得在和高层沟通时，要么只能单方面的听从安排，要么由于相互的不了解而使得沟通非常缺乏效果。而一旦这种习惯被养成，那么沟通的双方都会缺少耐心，以至于把增进了解以及互相传递需要什么的沟通机会，不再期望以及白白的浪费掉。

其实高层们要什么，并不是要下属根据下属自己看到和接触到的，进行信息的判断后给出需要的答案。而是给出选择，给出分析，让高层们自己做决定和下判断。就比如之前我的组里的data engineer lead，在我们讨论如何建立起新的数据平台并且如何能够实施好数据治理体系的时候，根据自己的理解给出了一定的建议。而当我问到还有其他的选择或者实施方式时，回答说没有。在我连续几次这么问之后，才回答我说还是有其他的方式，但那样子的解决方案需要至少几个m的投入，而且项目太大，觉得没意义。然而对我来说，判断到底是否有意义需要连接到更大的big picture里面，我需要的是不同的解决方案还有可能的benefit cost risk analysis，然后能够让我来判断到底值不值或者做不做。

由于各个层级掌握的资源，可调配的预算，接触到big picture以及联系能力，都不相同。于是在和上层沟通时，需要put yourself in the shoes。然而这句话说着容易，那什么是"put yourself in the shoes"呢，又有几个不专注于此方面的人们，不下苦功夫去学习和了解，就能够知道的呢？

hxsh2000

Pippa 发表于 2022-9-12 07:22
这不能怪你下属吧。你没有把不设限的条件说出来，人家不知道啊。下属依靠你了解企业的动态和上级的思路， ...

你引用的那个心得，是和之前的一个系列的，不是回复你的。这里说明的就是，在和高层高通时，重点和交流是什么？其实这里面有很多很多的交流，并不仅仅是技术人员们理解的Talk而已

773：我在另外一个帖子里面的回帖，讲的是talker and doer的。最近与不少做技术的人们或者一直在doer职位上长时间努力的人们聊天，发觉都很缺乏沟通交流，以及这些talk的目的是什么都很没有清晰的想法。并且很习惯的为了平衡没有得到升迁机会的不平，对于上升很快的人们，评价都比较偏负面。打算按自己的理解，分成几段说说这个话题吧，想到哪儿就说到哪儿了。

775：所以第一点，沟通和交流，talk的一个重点，就是marketing你自己。而如何marketing你自己呢，就是把自己做的，紧紧依靠在公司，部门和上司的战略和任务上，给大家建立一种你紧靠核心，做的事情和项目，都是在最重要的那一部分里面，并且你有经验，有足够的做成功的经验和能力

783：其次，沟通的基础是什么？是根据对方不同的层级，不同的风格，不同的背景，都需要有不同的沟通策略，而基础就是要去熟悉和了解这些信息。
由于各个层级掌握的资源，可调配的预算，接触到big picture以及联系能力，都不相同。于是在和上层沟通时，需要put yourself in the shoes。然而这句话说着容易，那什么是"put yourself in the shoes"呢，又有几个不专注于此方面的人们，不下苦功夫去学习和了解，就能够知道的呢？

hxsh2000

Pippa 发表于 2022-9-12 07:47
这个痛点几乎是无法避免的。因为高层人员更替会影响整个企业的战略方针。STL的更替速度甚至比上面还要快 ...

“我始终坚信人才才是企业最珍贵的资产（当然数据也是一种资产）。缺乏一群对企业如数家珍并赋予热情和忠诚度的核心人员，企业很难把战略构思变成现实。”

在传统的领域和职业，我非常赞成这种人才论。

可惜在新的领域，特别是数字化以及数据分析领域，我认为一群对企业如数家珍并且多年忠诚的核心人员，反而会成为这些核心战略和技术转型的制约和限制。这块领域的接受和更新非常快，那些你认为的最珍贵的资产，是跟进不了新形势的演变的。而由这一类型的人才去领导数字化和数据分析领域的转型，很难成功。我在这个帖子里面也不停的强调我的看法，一代技术和理念的更新，人们可以通过经验和知识更新来补足；当之后一代技术和理念更新后，人们是很难再跟得上了。我这个理念，也包括我自己，下一代技术和理念更新的时候，我应该也很难去拥有足够的想象力和能力去引领更新换代了。

Bessy

Pippa 发表于 2022-9-12 07:47
这个痛点几乎是无法避免的。因为高层人员更替会影响整个企业的战略方针。STL的更替速度甚至比上面还要快 ...

data hub的思路应该没有问题，因为这是个IT问题， 大部分公司都直接或间接的在实施。 report hub 就是在骗外行了，因为这不是单一领域问题。

Pippa

Bessy 发表于 2022-9-13 07:08
data hub的思路应该没有问题，因为这是个IT问题， 大部分公司都直接或间接的在实施。 report hub 就是在 ...

我们公司的data hub项目其中一个deliverable就是report hub。上一次系统换代，公司花了五年时间，动用了十几个核心人才，确实做出了非常好的report hub。参与的同事们不但精通公司各部分的运作流程并且从系统开发就开始参与。公司当时也愿意花钱花时间培训他们。可惜的是report hub做好之后一年左右吧，公司裁掉了这部分人。这次系统换代又来了，核心人都不愿意参加项目，大家百般推脱。暗地里大家都说，系统越差越好。可笑吧。

hxsh2000

Pippa 发表于 2022-9-13 07:24
你所说的数据核心战略只有在与公司运作完美整合之后才能产生应有价值。如果无法真正整合，那就是又一个烂 ...

我觉得有必要，因为我不觉得是行业的问题，虽然行业有影响。数字化和数据分析的整合是大趋势，各行各业都在慢慢的走在这条道路上。

我这么认为是因为我不觉得你深入的理解数据和分析这一块，所以不认可你对这块的结论和评价，并且在数据分析这块不具备专业性，所以给出的结论，我认为可能误导新人对这块领域的理解，所以我会加以澄清。

所以我一边很感谢你的分享，以及观察到的现状；却不认可你对现状延伸出来的分析，评价以及结论

Pippa

hxsh2000 发表于 2022-9-13 07:42
我觉得有必要，因为我不觉得是行业的问题，虽然行业有影响。数字化和数据分析的整合是大趋势，各行各业都 ...

我又不是你们这行的，当然没有你了解数据行业的发展。但我对企业整体运作的观察应该也有你看不到的角度。好了，不歪楼了，楼主不喜欢，我删了我上面的发言就是了。

hxsh2000

Pippa 发表于 2022-9-13 07:27
另外我上面说的意识不是让企业核心人才去领导数字化项目，但他们需要得到高层的支持，能有足够的时间投入 ...

这个观点我非常赞同，开篇我就认为数据分析是集业务，数据，以及技术于一体的解决方案。业务如果没有足够的参与并且投入，结果从业务的角度来说，项目肯定是失败的。

可如果这块项目是技术部门主导的，那么最终从技术角度来说，可能会被定义于成功。毕竟业务和技术，本来对于成功的定义，实施的优先性，预算只要用在那个方向上，甚至是这个转型的vision and purpose，都有着巨大的定义上的不同

hxsh2000

Pippa 发表于 2022-9-13 07:44
我又不是你们这行的，当然没有你了解数据行业的发展。但我对企业整体运作的观察应该也有你看不到的角度。 ...

是的，非常赞同。你是从risk management and assurance，并且是非技术人员，连同是公司里面的核心老员工的视角来理解和看待人才以及这块的。所以连续性，低风险，以及可持续话既是重点，也是对自我的认可

而我是新员工，我所带来的是专业性和新思维方式，需要打破原本的思维方式以及运行模式，也才能更好的体现自我的价值，做出成绩。也是自我的认可。

其实这么看待事情，不就是空降的外来人员之余公司里原有的人员，之间的最大的矛盾嘛。

还有我还是要继续说明，我没有不喜欢你的分享，我很喜欢，只是不赞同。

Bessy

Pippa 发表于 2022-9-13 07:35
我们公司的data hub项目其中一个deliverable就是report hub。上一次系统换代，公司花了五年时间，动用了 ...

你真会说话  整个team都被开了，还说他们做了很好的report.

Data 整合和data analysis是完全不同的两类人。动机和方法论都是不同的。

hxsh2000

在整个data and analytics体系里面，根据DAMA里面的描述，在刚开始建立起一套strategic data governance and data architecture principles后，就得开始着手统合公司里面的数据。而这一块会涉及到

Data Architecture: Enterprise Data Modelling
Data Modelling: Enterprise Conceptual Modelling

这一块在数据方面，非常的重要，因为只有把公司里面的所有数据的分类和负责人给理顺了，才可以给接下来的业务和数据部门进行有效的数据整合，并且给与技术团队加以指导设计和实施。

那这一块到底需要如何做呢？当然是找顾问公司并且给与指导了。对于公司来说，最重要的是根据business needs来进行设计和分析这些level 0 / level 1的数据模型。这里面就会涉及到不同部门对于如何整合数据的不同看法，也就是俗称的可能的主导权。

1. 主要根据公司内部的business needs以及technology roadmap为主要需求来源，找能够提供很好的数据分析的顾问公司，对内部的需求进行以上的两种建模，建立数据的分类和库。这个比较受公司内部非CXO们的欢迎，包括中上层管理层以及核心SMEs

2. 主要根据市场上的industry best practice，购买这些核心数据的分析和设计。一个取向是按已有的流程以及技术驱动的，比如SAP，Oracle，IBM在做了很多流程和系统的实施过后，针对特别的行业进行流程以及系统的优化，并且提供这种industry best practice的数据管理以及分类的建议。这个比较受技术以及系统部门的欢迎

3. 主要根据市场上的industry best practice，购买这些核心数据的分析和设计。另一个取向是按商业以及业务价值，和最大化商业以及流程的目的为驱动的，比如麦肯锡，波士顿咨询，四大数据战略咨询等，针对特别的行业且从商业和流程的角度，给与如何设计和分类数据，并且能够帮助最大化的商业价值以及利用这些数据，相当于对于已有甚至未来的整个数据分类的战略咨询。这个比较受到高层的支持。

cxu18

我也想转analyst, 正在学习SQL， Tableau 中。我才刚开始看楼主的帖子， 看完了估计对找工作有很大帮助

hxsh2000

DAMA里面提及的相关标准：

Data Governance: ISO 38505
Data Quality: ISO 8000
Metadata: ISO 11179

hxsh2000

其实在大型的data program，动辄几十个m的项目，又对着各个部门里面数据和分析流程都有很大的影响的时候，常常建立起来共同负责这个program的steering committee都需要来自各个部门的核心经理们，并且代替各个部门的executive们来发声并且代表本部门的利益。于是在很多时候，能够给出的解决方案常常很难是最优解，然而却是能够得到大部分部门的支持，并且能够得以执行的并且大家或自愿或跟随的配合。

而在谈这块的前期需求的时候，也常常是暂时不负责这块或者受影响比较小的部门，发出的声音比较大，需要考虑到的影响也比较小，也更容易指出现时的流程有多么的不足和需要改进。而能够在现时负责的核心部门们，则更多的时候会结成台面下的沟通和交流，商量出还比较能够被大家共同接受的解决方案，然后引导未来的解决方案的走向，在现有的之上进行发展。

那么进入到这个data program里面的时候，你代表了哪个方面的利益，就必须为这个部门发声并且尽可能把方向引导到对部门有利的。而既能多联合更多的部门支持，又能代表本部门利益的，往往能够得到更好的额名声以及被认可。通过什么途径呢，就是一直保持好和最高层通畅的沟通渠道，及时获取更多的战略层级的信息以及方向，进行及时的分析和解读，向着有利的方向引导。

之前工作过的公司，参与进一个集团公司层级的数据分析项目，在整个data program立项时，高层在讨论要不要设立这个公司层级的项目以对整个公司的数据分析进行各个项目的跟进和高层介入统筹资源投入。当时我的上司原本就负责着这块的很大一部分，所以对于公司层级的新项目立项并不热衷，觉得没有必要，打算在讨论时建立不需要。然而当时我刚刚去和大项目的负责人讨论事情就顺便问了这个data program到底是做什么的，并且为什么需要，结果答复是这是核心项目，之后讨论是否有必要更多的是走过场，支持度非常明显。最后项目通过也没有任何的反对声音，我也进入了这个项目组

hxsh2000

最近开始参加行业里面对于未来能源战略的研讨会，会上也让大家brainstorm对于未来十年以后能源和网络会是什么样子，由于大家有不同的职业背景，于是很多时候的讨论的切入点非常不同，也能够让大家相互的启发。

可在这种在与会时才拿到足够的信息然后参与讨论的会议，自己都会非常的吃力。小时候起眼睛是先天性弱视，就是没戴眼镜只能看到0.2/0.3，戴了眼镜也只能看到最多0.4，于是四岁多就戴着四百多度的远视镜。而这样子的结果，是从小到大上课时几乎不知道老师在写什么，因为常常看不到写什么。而开始工作后呢，在会上会放幻灯片，而离得比较远的时候呢，会几乎看不到写的什么，所以参与进去讨论的可能性也很小。比如这次研讨会，主办方放了不少现阶段能源用户们的各种意见和期望的调查结果，然后进行话题分类，让大家进行讨论。在这种时候，根本看不到那些具体的用户调查问题和结果的时候，参与讨论的机会也并不多。

bbjvc

Pippa 发表于 2022-9-11 21:40
我分享出来也是这个意思：大企业很难真正实现中央数据平台，因为资源很难满足需求。这个需求除了是做出怎 ...

我觉得很多公司其实没真正分清data stewardship 和data governance的区别，governance是建立系统和规则，要想建立统一的企业数据平台，这个必须是独立于business unit外统筹全局的，但是data stewards应该是分散到部门的, 这些人至少应该先是SME，然后才能配合govenance policies来进行数据的采集和处理。

在职位上，往往Data Anlyst和Data Scientist都是分布在Business Units,集中的数据部门大多由架构师和工程师组成。

hxsh2000

财务部和工程部，真的是两个非常不同的部门，对于技术的使用和想法也都有所区别。

在财务部，使用标准的，成熟的，甚至已开发的application / tool来增加使用功能和提高使用效率非常的常见。最常见的就是使用Excel (非财务部门的，比如IT或者数据团队，总认为能够找到替代Excel的更现代的工具或者系统，然而几乎都失败了)，或者通用数据库连接Excel，亦或者成熟的财务软件和应用，如SAP Finance, Oracle Hyperion, IBM Predictive Analytics。

而在工程部门，很多都有着工程加IT/CS双学位，技术能力那是杠杠的。由于工程师们有着非常强的动手以及造出新东西的能力，于是非常喜欢和擅长开发新的工具，而非使用已有的工具和系统(毕竟已有的有着太多的限制)。经常性的在一些标准性的系统里面有一些功能觉得没办法达到想要的时候，就自己写代码做出客制化的应用或者工具补足。

所以在协调这些部门的要求的时候，经常性的要理解这些部门虽然在说一样的需求，然而内核，背景，动机是完全不一样的。我连续两个工作都混在工程师的队伍里，渐渐的也开始理解和习惯这种风格了。而为什么经常性的，跨部门的中心化的数据分析团队，往往来自于工程部门呢？也经常是由于在不停的解决问题的过程中，工程部门常常已经建立起一些比较集中的数据库甚至部门内部的数据团队，这样的技能升级以及过渡会相对的平顺。而为什么在工程部门的数据团队成为了公司层面的中心化的数据分析团队后，Chief Data Officer / Chief Analytics Officer这种最高的领导往往不是这些部门上来的呢？那是因为工程师背景的数据团队，对于开发新工具来解决问题的兴趣，往往大大的高于deliver commercial / business value(从公司战略和财务的商业角度，看到的commercial value)，也往往缺乏非常有效的流程或者框架来进行管理。于是这种数据分析的最高职位，要么来自战略或者业务团队，要么来自IT团队

hxsh2000

美联储的加息节奏越来越快，一方面使得公司的借贷成本原来越高，由此借新债要么需要多还很多钱，要么借不到那么多的钱；另一方面公司的估值也会越来越低，那些往后快速增加的所谓的未来预估，通过NPV的高利率算进去，得到的价值也会越来越少。更多的，会影响到公司的投资属性，是否值得投资者们的热捧和投资，对于那些不停的投钱而暂时盈利利润落后的企业，会受到重新的检视并且价值重估。

还是那句话，公司估价的下跌，公司盈利和利润前景受影响，更重要的是公司股价的下降，那么决策层级的决定，是不会太过在乎什么蓝图，什么中层觉得这个重要那个重要，什么这个那个可以创造价值的，就是目标明确的砍预算，砍投资capex，砍人员数量和一般的开支opex。七年多前经历的那一幕，最直接的方式，就是矿价每下跌一百美元一吨，整个business unit砍100 million的开支。

Sheehans

厉害

hxsh2000

和朋友在近期的一个比较有趣的讨论，关于公司的Enterprise Architecture的话题。现阶段，EA这块还是归于IT技术部门管理的，可其实根据TOGAF的定义，Enterprise Architecture更应该独立于IT部门，属于公司流程和系统的范畴。可由于在现阶段整个公司的架构上，即CXO的工作分配上面，除了IT部门以外，也很难找到可以拥有这个设置和维持EA架构的部门了。

在这个EA构架的定义中，Business Architecture是核心，由此来定义Application Architecture, Data Architecture，然后才根据这两项来构架Technology Architecture。这四个构架应该互相影响，互相促进也应该互相制约。然而由于现阶段IT部门管理着EA这个职能，使得以技术为底色的IT部门在建立整个Enterprise Architecture的时候，很难建立和维护好Business Architecture，这块在很多公司里面，经常性的是完全缺失的或者只是存在于名义上或者文档中，于是IT部门做起来的时候，就往往无法从最核心的Business Architecture出发，而从技术为主导来建立整个EA的架构。所以经常性的，在做Visionary或者Roadmap的时候，反而从Technology Architecture为基础，来建立和影响Application Architecture, Data Architecture。

我认为这是不应该的

Enterprise Architecture:

hxsh2000

最近好像有很多很多的事情，主要也是之前计划完成的体育项目，赛程已经快开始了。一个明天，一个十一月中，而一旦这些比较有挑战性的又没有准备的非常好，就会开始有压力，有些忙乱。

而工作中，有点在刚刚开始的时候，摊子铺的有点大，几乎所有数据和分析相关的，都参与进去了。现在得更关注那些重要的，也需要好好的理理顺了

yaro

谢谢分享

hxsh2000

忙活了好一段时间，终于给管理层做好了各种数据治理框架，数据治理运行模式，数据以及分析的运行模式，等等的介绍和对比，并且把这三个重要的基础框架和运行模式给定下来了。接下来就是找顾问公司，设计和做出未来几年实施的路线图，在年底前再做一次presentation

DAMA (Data Management Association)作为比较开放性的，并且非常受欢迎的数据治理框架，是非常好的中大型公司的选择。而其中的数据质量控制和管理，则继续采用ISO 55001的框架。两者相辅相成，能相互补足关注点的不同，覆盖整个数据分析治理，从源数据进入系统前的采集开始，一直到最终端的数据使用以及分享的整个数据生命周期。

而从DAMA DMBoK的角度和切入点来说，管理着数据治理的内容，往往可以成为主要协调者，来做数据分析方向上，非常visionary & strategic的工作，比如Data Strategy, Roles & Responsibilities, Policies & Standards, Issues, Valuations。并且与每个细项都有交界以保持所有的数据分析活动能够符合数据治理的总架构。

hxsh2000

周二被有合作关系的顾问公司邀请去参加了Snowflake Data Cloud World Tour Melbourne，中间过去听了一场Snowflake Data Governance Management的讲座，还有一场能源公司过去几年的数字化和使用数据分析提升公司竞争力，并且如何使用Snowflake帮助达成目标的讲座。结束后还参加了能源行业私下的聚会，互相认识并且交流经验。

Snowflake还是非常的厉害，销售部门澳新才十来号人，遍布各个城市，每次都得大家飞来飞去的一起合作和准备。

xiaoyusteps

谢谢分享。感觉楼主有很多思考，开个油管频道吧，必订阅

yaro

感谢分享

hxsh2000

现在世界上的公用事业和政府部门，很多的都在讨论透明化数据和open data。ABS澳洲统计局的数据，比如Housing: Census，也是比较有意思的数据集，而这些数据集，都需要从很多的部门集成一定的数据才能做到的(https://www.abs.gov.au/statistic ... nsus/latest-release)

大家可以想想，如果要回答ABS Housing: Census的关注点问题，需要用到哪些部门，哪些数据集呢？

Key questions in 2021 Census
How many bedrooms are there in this dwelling?
Is this dwelling: (Owned outright; Owned with a mortgage; Purchased under a shared equity scheme; Rented; Occupied rent free; Occupied under life tenure scheme; Other)?
Who is this dwelling being rented from?

How much does your household pay for this dwelling?
What is the person’s residential status in this dwelling?
The questions from the 2021 Census are output into variables. To see descriptions of the variables, including data use considerations, relevant to this topic see the 2021 Census dictionary: Housing.

hxsh2000

我自己是很喜欢使用我自己喜欢的词汇和概念，来给管理层讲解整个数据和分析的概念的。主要是这些是我非常习惯使用的，并且觉得非常适合我自己的，简化后作为可以非常方便管理层理解的，看待整个数据分析的涵盖方面。

首先，我喜欢使用Business, Data, Technology的视角来讲解。这个也是我最近有点纠结而最后找到的觉得非常适合从总体把握来说明这个问题的。之前好几周，因为要给管理层做future state data and analytics的报告，开始的时候还是习惯性的开始思考，引用那些市场上比较经典的lakehouse以及best practice data flow，再辅以在这个方向上的各种可能选择。最后觉得如果做这个报告和建议，那么和技术部门以及数据构建做出来，并且给高层做的报告有啥区别呢？最高领导层真的有兴趣知道这些吗？或者听了后理解的了或者有帮助做决定吗？

于是我使用了我自己的一套，我自认为从更广阔的视角，而非从比较技术化的方面，来做这个报告和建议。而这也恰恰使用了我上面说的，从Business, Data, Technology的用户群体，到底需求什么，从而引出这些用户群体各自的Future State。而这又联系回我之前在这个帖子里面一直讲到的，Single source of truth到底是什么的四个层面。

由于管理层，除了IT的大老板，其他的几乎都是非技术部门的，我统称Business Group。那么到底对于Business Group，需要知道的Future State或者需求是什么呢？
那么肯定是需要有accurate and consistent的报表和数据分析，反应现在和未来的行业，公司，各个部门的状况。而这个细分为三个层级，SLT和各个部门的大头，其实只需要Executive Summary；中层经理呢，是能够从相同的数据源对于大头们的Executive Summary，做出analysis以及work on the focus area；还有对于Operations Staff，那么更多的是从相同的数据源，能够得到actionable insights，指导每天工作的重点并且需要完成的任务。

一切从Business Group的需求和Future State谈开来后，强调一切需要以Business Group为准，毕竟SLT里面还是以非技术的业务部门占主体的。这么个开局其实是非常容易得到各位大佬们的支持的。于是就需要说明如何实现这些呢，就自然而然的引出了我非常喜欢的four levels of standardisation for single source of truth，辅以从Data Group, Technology Group在其中如何一起共建Future State的方面。

4 Levels of Standardisation for Single Source of Truth:
1. Standardisation of Data Architecture (Technology Group main focus, with Data Group contribution)
2. Standardisation of Data Assets (Data Group main focus)
3. Standardisation of KPIs (Data Group and Business Group main focus)
4. Standardisation of Visualisation (Data Group and Business Group main focus)

很快的讲解了以上的逻辑后，很快的我就转到了Data Group future state的data and analytics development and operational model，而后转到Technology Group future state的简化版本的Lakehouse architecture。

而和预期的类似，大家在Data Group的讨论参与性，就已经开始下降，更多的关心是未来的operating model还能够让各个部门拿到需要的数据，且能够提供self-service capability，于是确定了Hybrid operating model，就是中心化的数据分析开发团队，掌握着数据开发的权利并且拥有Certify每个部门self-service开发数据分析用于公司层面报告的权力，而同时提供uncertified zones给各个部门提供self-service的再开发机会。于是也满足了各方的需要

而最后的Technology Group的Lakehouse试图和建议，几乎就没有谈论，也不是我非常有兴趣重度参与的方面，可以感觉到以业务方向为主体的SLT也没有太多的过问。就留下了接下来和技术部门一起商讨一起决定这块未来的蓝图

于是我希望的和涵盖的Business Group以及Data Group的提议，就都通过了。由此也拥有了对这两个层面future state一定的解释权。