中台详解系列1什么是中台.docx
《中台详解系列1什么是中台.docx》由会员分享，可在线阅读，更多相关《中台详解系列1什么是中台.docx（128页珍藏版）》请在冰豆网上搜索。
中台详解系列1什么是中台
1.最近处处惹人爱的中台到底是什么
在当下互联网圈子里要问什么最火莫过于中台这一概念了，各大公司都开始了一轮跑马圈地似的中台建设，那么到底中台是什么呢？
本文我们就来谈谈这个话题。
什么是前台，后台
在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。
所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。
用户对产品的认知与体验也由此而生。
比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：
一个绿色图标的应用，里面有我的A,B,C好友。
而后台则是包含两个部分：
∙企业的内部管理服务的统称，如：
内部的CRM，ERP等；
∙为前台提供服务能力的，如：
数据压缩能力，并发等。
后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。
在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：
图：
前后台模式
总的来说就是在应用中后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。
中台的白话解释
在开始谈论中台之前，我们先要明白当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新业务场景。
这种前后台反而是公司最省事省力的一种提供服务的解决方案。
因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。
实际上中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。
在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。
而作为实际用户真正接触的前台业务，如：
APP，小程序，网站等，必须要快速迭代新的功能才能让用户感知到。
而在这个大背景下带来的矛盾就是以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。
这样的后台变得越来越没法去快速响应前端变化所带来的改变。
原来的前后台模式的这种直接关联决定了，两者的冲突不可避免。
例如：
传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式（拼团，一元购等），导致每次活动页面开发的时候，不仅需要前端重新设计页面，从后台接口提供与数据表都要重新设计。
这无疑大大拉长了我们的需求响应时间，很有可能会导致在活动模块还没开发完成，我们的风口就已经过去了。
因此我们需要一个能最少改动就能完成大部分需求的解决方案，这就是中台。
中台解决方案到底是什么呢？
让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易的理解这个概念了。
首先请大家想一个问题，在一家客流量非常大的餐厅中我们要如何缩短客人的等待时间呢？
相信很多人的第一想法就是增加多名厨师，但是大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的，而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里，厨师人员就显得非常冗余了。
而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考。
也就是将做菜变为：
图：
做饭那些事儿
通过这样的拆分后我们可以发现无论是做什么菜系，买菜与配菜都是共有的两个步骤，我们完全可以只需要增加一位配菜的小哥来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：
图：
“中台”餐厅
这样我们每一位厨师新做一道菜时没有必要一定要从买菜，洗菜，切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究不同的创意。
完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人就解决了所有问题。
回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。
厨师是我们的一个个业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系，而在业务多元化后洗菜，切菜，配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可，当然这里的配菜小哥就是我们的中台。
所以说有了中台之后我们的前台业务就可以快速尝试迭代，不需要每件事都是从0到1开始了。
让我们再站在架构的层面来看看中台对整个系统业务所起到的作用。
假设我们是一个电商平台在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，就像下图：
图：
传统架构下的业务系统
而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务前台的特征加入适配。
这样造成的结果：
∙后台的每一个模块都需要加入与前台适配的部分，从而大大加大了开发量；
∙每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量；
∙当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。
当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知的使用各项服务而不需要单独设计通道，我们的系统也就简化成了这个样子：
图：
中台化后的业务系统
通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。
用一句话来概括就是：
中台的核心本质就是服务共享，目标是支持前台的快速创新或试错，而实现的手段是微服务架构、敏捷基础设施和公共基础服务。
中台解决方案
那么到这我们可以给中台解决方案下一个定义：
中台解决方案的组成=能力输出+标准化中间件
让我们来一个个解释。
第一部分：
能力输出
所谓能力输出就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。
并在这些业务层面中去提炼哪些模块是以共性存在的，并会在每个新开拓的业务中不断使用，然后就把他归类到中台进行建设。
这也就是中台的一个重要的意义：
为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。
例如我们规划了公司的核心方向是视频方向，未来可能会涉及的业务形态有：
∙在线视频
∙视频直播
∙短视频
∙......
分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为：
∙在线视频编辑
∙视频压缩
∙多人点播
∙......
完成拆分后我们就可以通过中台去实现这几个通用模块。
值得提一下的是虽然这里在说中台要考虑复用性，扩展性，但是要考虑多少，考虑多深这里又是一个非常考验产品功力的地方。
还是举上面的例子来说我在设计一个视频社区APP的积分商城系统时，需要将商城交易方式抽象为能力时，这里我们大体上可以抽象为如下三种交易方式：
表：
交易方式示例
但是同样的疑问来了，我们仅仅为了支持一个积分商城需要将中台的复用与扩展放大要考虑引入股票交易才使用到的撮合交易模式吗？
当然这里的案例比较极端我们能快速判断，但是在具体的中台规划中我们会碰到很多这种类似的范围决策，我们必须要按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。
第二部分：
标准化中间件（整合能力）
在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分就是需要做一个将每个能力进行封装，形成一个统一的可供前台业务端方便使用的中间件。
这里的统一具体表现在如下的几个方面：
∙不同终端中的叫法与含义；
∙定义统一化的输入输出；
为什么要统一呢，以往的前后台模式中同一家公司内的不同业务如：
直播项目组，短视频项目组各自为战的时候，经常会出现一个事物被不同项目因为场景化的需求，而出现两个称呼的现象，但是实际上他们本质上是同一个事物。
这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍：
无法快速对接。
例如：
就那一个用户昵称这个字段来看，在不同项目组中的应用中可能会叫：
用户名称，用户昵称，称号，花名等，而在数据库中又可能会有不同的字段名称：
username，UN，name等等。
因此我们需要一个中心化的产物帮助我们定义好这些个通用属性，使在公司中不同的业务端都能统一。
面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。
以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候，无论具体是什么业务前端都会是一个叫法，一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。
最后
在竞争日趋激烈的互联网行业中，如何低成本又快速的完成业务创新去占领市场是每个企业所追求的方向，而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。
articleCommentId{0}articleBiz{Mzg5OTE4NzI2MQ==}
2.什么是中台？
中台在OTA领域如何发力
近年来，在互联网企业中，中台是个非常热门的词，那么到底什么是中台？
中台又能做些什么？
在旅游行业如何发力？
本文试探讨一二。
互联网企业的中台战略
在互联网企业中，阿里巴巴算是最早提出“中台”概念的了。
在2015年年末，阿里巴巴集团进行了一次组织架构大调整，组成了“中台事业群”，并喊出“小前台，大中台”的管理模式。
2017年5月，《企业IT架构转型之道：
阿里巴巴中台战略思想与架构实战》，推动了中台思想的发布和中台的建设。
而从18~19年这两年时间，大型互联网公司纷纷宣布开始实施中台战略。
2018年9月，腾讯新成立了技术委员会，宣布未来将打造技术中台。
2018年11月，美团尝试打通美团APP全平台、大众点评、摩拜各个业务之间的数据，构建数据中台。
2018年12月，京东组织架构调整，决定将在系统中增设中台。
2019年3月，字节跳动被曝出正在搭建“直播大中台”，抖音、西瓜视频、火山小视频这3款APP的直播技术和运营团队将被抽出、合并，支撑旗下所有的直播产品。
为什么都在做中台
如果公司只有一条业务线，前台面向用户实践落地，后台保证内部高效运转，一个前方落地，一个后方保障，快速联动灵活应变，非常符合互联网企业所讲的“唯快不攻”效率优先。
但当公司发展到一定阶段，多条业务线并行，单一的架构设计不能快速反应，前台多业务线铺开，后台却堆积着需求，效率大大降低，这时候，中台就应运而生了。
中台能做些什么
中台，是前台与后台的交汇，第一个作用就是整合共享，避免重复建设，降低成本、提升效率。
其二，中台能够发挥赋能复用的作用，沉淀企业核心竞争力，更好地支撑新业务的发展。
目前，互联网公司运用较多的中台由技术中台、数据中台、业务中台构成。
技术中台打通底层技术架构，高效协同，提供简单、易用、可靠的基础架构，支撑前台、业务中台和数据中台快速建设。
数据中台构建核心数据库，灵活调用数据平台，并提供数据分析、挖掘、处理等服务。
业务中台将业务能力和经验转化沉淀，为前台业务创新提供支持。
中台在旅游行业的实践
那么，作为旅游行业从业者，旅游行业有没有实践中台作用的企业呢？
我们看到，OTA反应迅速，运用中台轻量化实践了较好的效果。
OYO酒店2.0模式
位于西安的泉馨酒店是一家只有20多个房间的小型宾馆，受限于区位条件，入住率和营收长年低迷，在OYO酒店2.0模式运营后，入住率提升到95%，营收更增长超过120%。
资源整合，精准发力
OYO酒店2.0模式，主要由OYO数字化中台推出的“城市酒店供需地图”构成，它整合线下过万家酒店的数据积累，以酒店为中心梳理周边人流、重点POI、竞品、消费者偏好等关键信息，为一线团队攻城略地和精细运营提供可靠的数据支撑。
在关键的定价策略上，基于大数据和人工智能的中心运营系统动态调价，更直接驱动单体酒店收益增长。
携程TrainPal
2018年2月，携程上线了一款主要面向欧美铁路市场的手机应用，以“拆票”为特色功能的手机应用：
TrainPal。
一年之后，已经有100万下载量，而这款APP前期的启动团队其实只有4个人。
经验赋能，快速复用
TrainPal底层技术尽可能复用携程的系统，就是所谓“中台”部分，所有的流程都尽可能的“中台化”，利用已有的经验赋能，快速复用输出，前端很轻，团队很小，但足以支撑打开欧洲市场。
中台模式的思考
中台是互联网企业发展到一定阶段，为解决企业实际痛点而产生的。
由于前几年移动互联网的快速发展，大部分互联网企业以事业单元或业务条线切割，快速扩展业务占领市场。
在快速发展的背景下，这样的模式是一种有效的方法。
但随着互联网发展逐渐放缓，企业自身也发展到了一定规模后，原来的模式逐渐显露出了问题，各事业单元间资源无法共享，存在重复建设和资源浪费。
发展新业务时，各事业单元间打通困难，一切要重头开始。
所以，中台是跨事业单元，跨业务条线的枢纽和资源的共享整合，目的是为了降低成本、提升效率，并能沉淀能力找到新的增长动力。
并不是盲目跟风、炒作而出现的网红热词。
而对于旅游行业来说，如何通过开发环节打通，数据分析运营，沉淀核心业务经验，研判潜在市场，为企业带来新的增长空间，或是中台部门努力的方向。
3.什么是中台，什么不是，所有的中台都是业务中台
从今天开始打算写两三篇文章，力求说清楚什么是中台，什么时候要考虑建中台，怎么建中台。
今天是第一篇，目标是厘清什么是中台。
中台的概念一热，很多似是而非的东西都在往中台的概念上凑，一下子出现很多中台，如业务中台、数据中台、技术中台、算法中台、移动中台等等。
特别是很多原来称作平台的，现在也都摇身一变成了中台，赶时髦。
一个概念太过宽泛是不利的，如果随随便便都是中台，必然导致很多所谓的中台项目失败，导致中台无用论。
所以有必要对中台的概念做一个比较准确的定义。
1什么是中台
要定义中台，重要的是要能比较明确的区分中台和平台。
中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。
中台是支持多个前台业务且具备业务属性的共性能力组织，平台是支持多个前台或中台业务且不具备业务属性的共性能力。
为什么要强调中台必须具备业务属性？
可以来看一个例子。
我们可以分析什么叫数据中台。
如果一个企业把所有业务的数据都存储在Oracle里，我们能说这个Oracle数据库是数据中台吗？
显然大家都会说不是（否则中台不是几十年的老古董了？
）。
那么现在很多企业换成了Hadoop，所有业务数据都在一个Hadoop集群里，能说是数据中台吗？
显然也不是，这个Hadoop无非跟原来的Oracle一样存了一堆数据而已。
有人说这是因为这个Hadoop集群只是一个系统，中台必须是一个组织。
那么我们再加上建设和维护这个Hadoop集群的团队，整个加起来就是中台了吗？
仍然不是，因为这个团队是不需要为业务负责的，不具备业务属性。
而现在大家比较公认的数据中台，指的是确保OneID、OneData得以实现的组织，使得数据不再是各前端业务独立管理，而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合。
之所以这样大家会认为是名符其实的数据中台，是因为指标一定是面向业务的，数据仓库的建设一定也包含了一些业务逻辑。
所以那个大大的Hadoop并不是数据中台，而是大数据平台。
我们还可以看到是中台还是平台与所在的业务环境相关。
同样的能力对A业务来说可能具备业务属性从而是中台，但对B业务来说没有业务属性从而是平台。
比如说IDC建设和运维对AWS来说可谓至关重要的业务中台，而对绝大多数企业来说只能说是平台。
PaaS平台对SaaS厂商来说是业务中台，但对绝大多数企业来说也只能说是平台。
所以，不具备业务属性的能力，即便是共性的，即便有一个专职的部门在做，即便对业务非常重要，也不能称之为中台，而还是应该称之为平台。
否则就会出现很多与业务八杆子打不着的各种中台，混淆视听。
因此，应该说所有中台都是业务中台，没有别的类型的中台。
数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。
中台的定义还要求以下两点：
1. 中台是一种共性能力组织，支持了多个业务。
2. 中台支持的是多个前台业务。
第一点不用多说，只支持一个业务的能力至少暂时不能称为中台（当然可以有进一步建设为中台的规划或可能性）。
之所以强调第二点是因为有太多的公司的业务不是靠前台打下来的，而是靠财务后台做账做出来的。
理论上可以有，但我们应该支持这样增强做账能力的中台吗？
对于那些专业提供做账服务的公司，还真需要这样的中台，但这时做账就是它的前台业务了。
中台的定义并没有限定中台的建设层次。
中台可以在很多个层次上建设，并不是说必须是企业或集团级别的。
BU和BG层面建设中台往往更常见，也通常很有意义。
即便更小的层面比方几十人的小部门，中台也很有价值。
比如一个小团队也可以做电商业务，这时如果有一套好用的电商中台那就帮了大忙了，而事实上业界也有很多公司在提供这样的能力（淘品牌可以说用的就是阿里提供的中台）。
2典型的中台有哪些
除了常说的业务中台，我们还经常听到数据中台、用户中台、搜索中台、推荐中台、内容中台、技术中台、算法中台、移动中台、研发中台等等一系列的XX中台的说法，但这些中台未必都是真正的中台。
前面已经说过，广义上讲业务中台包含了所有中台，不同的XX中台都是业务中台的细分方向，反映的是该中台在业务领域或者技术上的某些特征。
但大家受阿里的影响，往往只用业务中台来指称在线业务中台。
基于这个假定，当前典型的真正的中台大致只有以下几个：
1. （狭义的）业务中台：
一般指在线业务为典型特征的中台。
在OLDI（OnlineData-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。
但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台。
2. 数据中台：
一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。
同样，在OLDI时代，数据中台越来越重要。
狭义的业务中台也就是在线业务中台负责OLDI中的OL（Online），数据中台负责OLDI中的DI（Data-Intensive）。
3. 用户中台：
用户中台可以认为是一种特殊的数据中台，一般以用户ID统一、全域用户画像建设、全域会员体系建设等为典型特征。
用户中台很通用，比更广义的数据中台往往更常见。
很多企业没能力建设更全面的数据中台，但建设了会员中心等用户中台。
4.内容中台：
内容中台往往也可以认为是一种特殊的数据中台，一般以内容的采买、内容爬取、内容的加工处理、内容安全保障等为典型特征。
5. 搜索推荐中台：
这两个中台比较像，因为搜索和推荐的技术比较相似。
这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程，同时支持流程各环节的可定制能力，从而支持多个前端推荐搜索业务的快速开发。
当然还有很多其他根据业务需要建设的中台，比方说对美团/饿了吗来说，本地配送体系可以建设为中台，前提是这个体系不仅用于送餐。
在电商行业，往往渠道运营用单独的系统和团队来支持各个BU（一般按品类分），也可以说是中台。
3技术/算法/移动/研发中台当前基本不存在
一般来说，没有技术中台，这是因为以技术为典型特征，又具备业务属性的中台太难找了，没有一个很好的案例。
可以看看业界所谓的阿里的技术中台，包含了从IaaS到中间件等一系列在线业务技术，但能称这些为中台吗？
可以把里面每个模块都拿出来分析，保证你找不到一个跟业务相关的字眼。
所以这些并不是中台。
再看业界所谓的阿里移动中台，其实来源于阿里关于移动研发平台EMAS的分享。
人家阿里其实自称的是一个研发平台而不是中台。
还有业界把阿里的研发平台—云效平台—称为研发中台，这也是一种误读。
其实阿里自己也只说业务中台和数据中台。
其他的中台都是某些咨询公司或不明真相的群众牵强附会造出来的。
并不是说不能有技术中台，而是没必要特别的称作技术中台而非业务中台。
对于提供技术服务的企业，它的业务前台就是技术前台，它的业务中台就是技术中台。
比方说SaaS厂商的中台往往是个PaaS，这时这个PaaS可以称之为技术中台，但也是这个产商的业务中台。
同样的一个PaaS，对于大多数别的企业，就变成只是支撑业务但本身没有业务属性的技术平台了。
所以，为了避免混淆，导致把平台说成中台，不如坚持认为不存在技术中台。
同样的道理，移动中台似乎只对做移动应用开发业务（比如说很多外包产商）的企业来说才是中台，但对这些企业来说移动中台也就是它的业务中台，所以也宁可不搞出一个移动中台这样的新名词为好。
那么，什么才是研发中台？
华为有专职的研发部负责支持所有前端业务的研发，让听得见炮火的人指挥战斗，可能是名副其实的研发中台，但云效肯定不是。
据我所知云效团队主要是做云效这个产品，并不负责中台业务系统的研发。
不过，既然可能最有资格说是研发中台的华为也没出来趟中台概念的浑水，我们着什么急呢。
总之一句话，当前并没有好的技术/算法/移动/研发中台，那些出来宣传这些中台的要么是自己搞不清中台概念，糊涂，要么就是骗子。
不过没有这些中台说明整个行业在这方面的积累还不够，是一种不足，希望过几年有真正的这些中台出来。
这是关于中台系列的第一篇，目的是厘清什么是中台，什么不是中台。
下一篇将讨论什么时候要建中台及怎么建设中台，敬请期待。
4.什么是数据中台？
全面解读数据中台
伴随着云计算、大数据、人工智能等IT技术迅速发展及与传统行业实现快速融合，一场由数字化和智能化转型带来的产业变革正在孕育。
随着企业规模不断扩大、业务多元化——中台服务架构的应运而生。
“中台”早期是由美军的作战体系演化而来的，技术上说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。
阿里在今年发布“双中台+ET”数字化转型方法论，“双中台”指的是数字中台和业务中台。
数据中台是什么
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。
数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。
这些服务跟企业的业务有较强的关联性，是这个企业独有的且能复用的，它是企业业务和数据的沉淀，其不仅能降低重复建设、减少烟囱式协作的成本，也是差异化竞争优势所在。
广义的数据中台包括了数据技术，比如对海量数据进行采集、计算、存储、加工的一系列技术集合，今天谈到的数据中台包括数据模型，算法服务，数据产品，数据管理等等，和企业的业务有较强的关联性，是企业独有的且能复用的，比如企业自建的2000个基础模型，300个融合模型，5万个标签。
它是企业业务和数据的沉淀，其不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争优势所在。
建立数据中台的原因
数据中台和业务中台相比，面临的情况可能会更加复杂一点。
建立数据中台的原因：
∙大数据可以告诉决策者一些潜在的规律，以数据来证明或判断决策。
以往我们会用数据来证明我们的决策对错，现在我们用数据来引导我们做出对的决策。
在大数据时代，样本就是全体，大数据可以防止伪造和偏差。
∙数据催生人工智能。
数据是人工智能的根基，并且可以进行融合形成新的数据。
数据给我们无限的创新，让我们不停去尝试。
∙数据是机器人的指令，我们形成数据服务思维。
数据是不断变化的，让机器智能成为决策环节，运营就可以智能化。
中台的目标是提升效能、数据化运营、
升级会员 