2B领域主要集中在数据分析处理、各类型人工智能应用、云服务等领域。考虑到国内政府采购金额庞大，而智慧城市这个领域是通过专业的系统集成，将各类型技术进行综合应用的具体场景，是政府开支的重要方向。未来可能将会在智慧城市这个领域诞生一批伟大的2B/2G技术服务公司。

2. 细分行业前景及内在逻辑

       城市是一个复杂巨系统，智慧城市的范畴自然也是包罗万象，其中主要涵盖的方向有：安防监控、交通感知&控制、支持各类型智能IOT设备的基础设施、消安管理、城市综合管理、园区管理等，其中又以安防、交通两个领域最为重要。

       就安防来说，主要是服务于公安机关治安、反恐、稽查等方面的业务应用。由于安防主要依赖于视频分析/图像处理技术，而这一方向可以说是场景最为规范的人工智能应用领域，所以这一部分的市场需求已经得到充分响应，除海康/大华等传统的监控设备企业外，商汤、旷世等人工智能企业也已经涌现出来。在这一细分领域中，利用成熟产品能力构建公安智能化业务模式的项目仍然是政府采购中的重要部分。

       交通事关人的基本刚需，也是社会运转的必要条件。交通是人流、物流的综合承载；涵盖了公交、非机动车、私家车、空铁联运等多种出行场景。相较于“衣食住”的高度个性化，出行则有更多的规则限制，需要交警对出行人的行为进行严格约束。由于我国的特殊国情及发展历程，出行需求与供给的严重不平衡现状短时间难以有效改变，加之近来无人驾驶热潮的风起云涌，百度/阿里/滴滴/华为等头部科技公司纷纷下场参与，大幅提升了政府的关注度与投入。使得交通在智慧城市的场景中也成为了非常重要的一环。

       在智慧城市项目中，投资金额主要都集中在外场硬件设施上，大量的土建安装工作是构建上层智慧应用功能的基础，因而在城市中有良好承载功能的智慧灯杆也是各个项目中非常重要的一环。除了在系统构建时重要的基础作用，因为责任边界清晰、投资体量巨大、且易于把控风险，硬件设备的建设工作也往往项目中利润最丰厚的一部分。

3. 当前竞争格局

       由于政府端的信息化建设进度一般落后于企业，政务工作类型多样且多有因地制宜的情况。所以不同类型的政府项目一直纷纷涌现。在这一领域中，传统的系统集成企业如千方、易华录、海信、太极等公司已经耕耘多年，而BAT等科技企业出于业绩、数据等方面的考虑也纷纷加入这一领域。目前各公司的布局情况大致如下：

阿里：阿里在智慧城市领域的核心逻辑就是以高德作为客户的突破点、项目的控标点，力争将政府的各类型数据都汇聚于阿里云，在通过达摩院的算法能力在数据中探索增值服务内容。高德地图常年经营政企关系，加之具备地图数据、路况数据等优势资源，使其成为了阿里集团进军智慧城市的核心能力。阿里在政企关系方面的耕耘使得阿里起初斩获了多个“城市大脑”项目。阿里在项目交付中先是着重自研探索，随后通过收购分包等形式尝试培育自己的生态，然而投入产出比非常不合理，阿里也随之调整战略，并提出“被集成”口号，同时也大举入股千方。目前来看，产品方面阿里已经将目光聚焦于云服务，算法能力，底层数据等方面；商务层面阿里则通过品牌、业绩等优势直接培育项目或支持生态伙伴竞标。中标后阿里分配项目任务，将项目中的各项定制交付工作分配给浩鲸、千方等生态公司。

百度：百度常年在AI领域大量投入，且AI能力的最重要体现就是在无人驾驶场景上，其阿波罗战略也初见雏形。目前百度在智慧城市领域中主要还是关注智慧交通方向，通过政府项目获取路权资源，探索面向未来的车、路协同无人驾驶场景，并进一步完善阿波罗计划。百度在智慧城市领域中目标明确，不会轻易参与系统集成项目。虽然百度没有斩获大量订单，但其战略目标和执行策略反而是最清晰的，其产出也是最具产品化特征的。

滴滴：智慧城市最早可以追溯到高德首次提出“城市大脑”战略，而滴滴基本是在同一时间下场参与竞争，曾经一度组建了300人的专家团队。期初的竞争策略与高德类似，在经营政企关系的同时力图从内部孵化用于交通管理场景的产品。滴滴从战略上来看应该是通过获取路权来为无人驾驶场景进行准备，如果获得成功则可以通过无人驾驶完全颠覆现有出行模式，没有司机就没有抽成，也没有安全隐患问题，只需要部署足够的车辆就有望接管出行市场。然而由于一直无法取得路权资源或合同金额等任意形式的合理回报，所以目前也已经开始调整策略，已经有信息看出滴滴计划通过与新能源车企合作逐步过度到无人驾驶运营的场景中。

腾讯：腾讯在这一领域一直鲜有发声，印象中仅有此前0元中标某市云服务的消息。结合腾讯一直以来的风格，可以得知腾讯在这一领域中已经在稳健布局，未来应该会带着完善的产品能力体系正式的介入这一领域。腾讯在生态的培育方面一直都很出色，腾讯入场可能反而是破除当前行业积弊、激活市场的一个契机。

       就当下的情况来看，智慧城市已不是蓝海市场，但由于智慧城市本身的复杂性，导致此前介入的公司也没有形成非常显著的优势地位。未来想要在这个领域有一席之地，个人认为还是要找到合理的切入点，形成具有边际效应、有强大适配能力的能力平台，与其他专业公司共同构建良好的生态，避免与BAT等头部企业直接在系统集成层面进行无谓的竞争。

二、 智慧城市行业现状及普遍问题：

1. 地方割据

       智慧城市总的来说，由于各个城市都有其独特的传承，在基础条件、既有系统、发展目标、组织结构、工作模式等方面都有一定的差异，加之政府的业务系统尚未达到全面、先进的信息化水平，所以各地政府在完善自身业务系统时往往都需要高度的定制化服务，使得政府采购项目大多花落当地的相关公司，当地政府与当地企业往往野容易形成稳固的合作。但政府部门与企业的合作也会呈现出“一朝天子一朝臣”的特征，领导换届时的新任领导往往会有新的发展思路，一般不会在上任领导既定的规则中尝试做出自己的成绩。

       综上，各地政府的各类型系统都会不尽相同，很难将一地的经验快速复制到另一个城市。虽然我们在交付时提供的是开发好的系统软件，但却很难规模化的复制成果并产生边际收益。

       所以在执行项目中，应当设置合理的交付目标，不能单纯的以用户满意度为导向，因为所有围绕用户的定制化需求都是产品级系统研发过程中的障碍，都有可能导致智慧城市业务逐步偏向EPC模式，而不是开发真正能解决痛点需求的产品或能力。

2. 订单导向

       政府采购订单一般都是预算制，需要提前制定开销计划，也使得针对一个项目、一个系统的各项内容都需要一次就在预算环节编制好，甚至需要将多个采购项目归并在一个项目下进行申报。这一现状导致政府项目，尤其是智慧城市项目往往呈现大而全的特征。但在预算编制环节很难对用户需求进行全面分析，难以对多项建设内容的内在联系进行深度思考并构建一个完整严密的顶层逻辑规划，导致一个形式上完整的项目在建设中需要多个团队进行支撑，也就会出现团队各自为战的情况，缺乏业务层面挖掘。这样的交付模式将导致“烟囱”式系统的频现，所以往往难以触及最核心的业务痛点。相反，在项目交付环节中往往只会将注意力集中在管理人员上，通过“大屏展示”等表现形式上的努力来获取用户的认可。

       出于机制和规则的原因，项目的运作、执行模式难以发生重大的变化。并且大型系统的建设也无可避免的需要众多团队的协作，而各团队间的沟通内耗往往是项目高品质交付的最致命问题。所以目前行业内普遍存在着项目任务包罗万象，执行团队各自为战的问题，然而却出现了模块间弱关联甚至不关联的结果。此外，由于任务的切分导致工作推进时往往在不同团队间产生了互为因果的依赖关系，所以在项目某些环节推进不理想或者没有达到预设目标时，甚至无法追溯问题的来源，也即似乎按照计划完成了所有任务，但却没法收获圆满的项目交付成果。

       政府作为甲方必然能够理解大型集成项目的复杂之处，一般对于系统的实际功效的打折程度也会有一定预估。但是如果在项目中没有构建出内在逻辑架构完整，数据、业务流程合理可扩展，交互友好易用的系统，如果在后期的跟踪服务上也没有驻场积极响应，那么即便是像传统的业内企业一样去完成EPC项目都将没有优势，可能会出现虽然在项目付出了诸多努力，却无法巩固公司与政府间的政企关系，无法将客户变成自己的“根据地”的情况。也即以订单为导向可能会出现用户不断流失的情况。

3. 目标不落地

       出于经验、工期、团队等方面的限制，政府项目在执行中一般都是以应标为第一优先级，保证项目交付、结算是项目执行时的铁律。在这样的原则下，一般项目团队都会自然而然的积极响应主管领导的要求以确保验收，同时也就忽略了基层人员面通过系统处理实际业务时的真实痛点。加之项目执行中需要拆分任务、责任到人，一个需求的满足将关联很多人员，如果没有项目经理和产品经理通力合作进行梳理，很可能导致即便是研发团队响应了需求，也难以取得良好效果。所以无论是领导的个人喜好还是实操人员的真实痛点诉求，都有很大可能出现需求频繁变更的情况，也将一个个旨在打造智慧城市产品的项目，变成了一个个“软件外包”式的项目。

       究其原因，项目标书本身就有很大的解读空间，而智慧城市项目中开发的系统又不同于2C的产品，必须以用户需求为准，而用户往往又缺乏全面的IT知识来支撑准确的需求表达。导致所有收集的需求往往都难以直达痛点，又或者需求往往都是面对描述的，而不是面对问题的。

       于此同时，在项目的执行目标上一般有产品化的目标或计划，但却没有详尽、全面、触达痛点的需求做支撑。导致系统开发中的产品化目标容易陷入比较空泛的状态中，没有办法明确具体要完成的产品化内容是什么，在项目中开发的系统也无法在其他项目中简单快速的复制。这也从另一个角度解释了，为什么众多公司带着产品化的目标进入智慧城市领域，却发现不断向着EPC总包的角色去转变。

4. 商业模式

       智慧城市项目在模式上没有突破，本质上就是政府通过招投标对集成的信息系统进行采购，本质上就是EPC模式。这样的项目模式一般要经过立项、论证、预算编制、可研评估、招投标、设计、实施等众多的流程或步骤。一方面，项目的前期成本非常高，且项目流程中的变动因素很多，辛苦培育却不能开发结果的情况时有发生；另一方面项目的执行难度也非常高，因为规划不合理、需求不明晰等原因，导致需求变更，审计，结算等众多环节上都需要大量的事务性工作，且费用核减的可能性也非常高。如果能通过SaaS、PaaS产品形式来应对政府需求，那么就可以有效规避以上风险，这也是业内公司纷纷推行产品策略的原因。

        但产品也需要业务模式的支撑，因为越是复杂专业的系统，其使用门槛也越高，甚至脱离专业的操作人员用户自己可能是无法单独使用这些系统的，这也导致政府用户对于驻场服务非常看重。综上，优秀、专业的平台型产品+专业的运营人员来提供专业的服务，进而与用户签订长期稳定的服务协议是智慧城市领域中的理想模式，而且可以通过产品license和派驻人员撤离两个环节确保服务费用能够有效结算。同时在数据等资源的获取、整合、管理方面，驻场服务也将带来显著优势。

       虽然项目承包的模式还是有可观利润的，但其本质仍旧是是赚取人力、采购、设计等环节的差价，相关业务停工即停收，一方面波动很大，一方面也不具有产品的边际成本优势。而专业产品+驻场服务的模式在规避了EPC模式的弊端的同时，实现了高质量服务的高效的供应；也在回避了项目从培育到验收过程中的种种风险，可以通过服务费用的形式获得稳定的现金流。

5. 产品打造需要转变模式

       出于行业自身特点，一部分的智慧城市项目由各地有实力的公司承接，这些公司往往都仅占有局部市场，公司规模上能够支撑一个小规模的研发团队。虽然不乏有富有远见的老板愿意在研发上进行投入，但出于智慧城市行业本身的特殊性，产品的形成往往牵涉着GIS&高精地图、数据中台、可视化渲染等几个重资产的关键环节，所以这些局部性企业规模往往难以形成重量级的产品。此外，这类公司的营收模式比较单一，受行业景气度影响比较大，出现波动后也很难保持研发的投入强度。

       另一方面，近几年进入这个领域的科技公司也因为产品、行业规模等方面的发展没有达到设想，已经开始纷纷调整战略。从此前的在EPC模式上的白热化竞争，开始逐步抽身，开始专注于自身的能力图谱、战略目标。可以说通过智慧城市项目打造能够产生稳定现金流的平台型产品不再是这些公司的目标，而是将智慧城市项目作为云服务、无人驾驶等战略发展方向的试验田。出现项目机会后，这些头部公司将规范的平台及产品、服务切分给自己后，将剩余的定制化开发任务都分包给生态企业。未来可能将会以分政府部门、分业务、分功能的模式逐步填补这一市场空白。没有企业能够通盘解决智慧城市的所有问题，依托自身优势逐步构建专业领域的产品生态将成为主流。

6. 产业缺乏清晰的规划和标准

       智慧城市项目下涵盖的信息系统建设、专业服务等内容都是政府采购的刚需，各地项目也是层出不穷。项目中涉及的监测设备、IOT设备、高精地图、GIS引擎及地理信息等在各个不同项目中都有涉及，但没有根据城市进行综合整理、盘点，项目间的数据等资源往往不能兼容复用。未来的智慧城市显然应当是覆盖整个城市辖区，甚至在更大的地理空间上实现智慧，那么未来必然将由政府出面进行统筹，确保不同项目在建设过程中，都可以向拼图一样逐步打造一个覆盖全域、全参的智慧城市系统。

三、 智慧城市项目执行中的问题及策略：

1. 应熟悉政府运行的内在逻辑，分析内在的派系及立场

       智慧城市项目服务的对象一般都是厅局级的大型机关单位，这类单位一般内部派系复杂，难以充分掌握各方立场。所以在项目执行中，一方面难以判断厉害冲突，另一方面项目所必须的协调工作开展起来也经常困难重重。

       根据以往经验，直接领导项目的分管领导并不一定能够决定项目走向和进度，推动项目还是要依赖甲方内部的关键人员，搞清甲方内部组织结构，在关键部门/人员上进行突破才有助于推动项目中的关键问题。

2. 缺乏对甲方预期、需求的管理

       大型的集成项目难以通过简单的文字来进行准确全面的描述，依照方案描述打造系统时需要大量的人为解读，换言之项目方案只能约定项目的建设范围。加上政府部门工作中有相对严明的层级关系，所以很容易出现领导在项目上提出各类不切实际要求的可能性，这也是智慧城市项目中最常见的问题之一。

       面对用户不切实际的要求，一味的服从，单纯的寄希望于自身努力来迎合很容易让自己陷入被动。让甲方坐下来耐心的听我们讲解，能够有效顺畅的沟通才能保证项目顺利高效的推进。换言之，一定要有反制甲方的准备和措施，要有和甲方争论的底气和策略。虽然政府项目自有其特殊性，项目中也总是会呈现出甲方非常强势的状态，但是所有的政府项目都是一定有反制的条件与可能的。第一，虽然不能直接与上层领导产生冲突矛盾，但是在底层人员的沟通中，出现争执矛盾是很正常的，而且项目中也经常呈现“阎王好过，小鬼难缠”的局面，所以针对边缘人员进行反制是非常值得考虑的策略，即便局面搞僵了也可以作为上层更加透彻沟通的契机，而且这样的反制会让甲方明白我们也有底线，突破界限以后是无法从甲乙方关系上进行约束的。，在面对甲方诉求时，响应之前就应当有不同的应对策略。在研发目标、策略都比较明晰的情况下，在前期已经比较尽心尽力去迎合甲方的情况下，面对源源不断的个人好恶层面的需求，完全可以通过拉长响应周期、分批分次响应、点对点响应等方式来拖延并减轻自身的工作量，毕竟在这类型的需求上进行投入不会有任何附加的回报；而面对能够切实解决痛点的需求，则应该加大力量投入，并借助项目的良好契机对产品成效进行检验。

       综上，对甲方需求进行有效管理；对需求进行辨别，有选择的积极响应是控制项目交付节奏，保障项目有效产出的最有效办法。

3. 任务拆解、目标细化容易掩盖问题

       处于项目体量原因，必然会出现多项任务由多个团队完成的情况。在对每一个团队或个人设置了任务及目标后，会出现一些对项目执行非常不利的情况。首先，个团队分别完成自己的任务，非常容易导致忽略其他团队诉求的情况，在项目中大家互为依赖条件的情况下，很容易因为链条中的一环影响了整个项目中的进度。其次，任务的细化会导致推进路径、责任的划分变得非常单一，导致在项目中出现进展上的问题往往无法提出有效的应对策略，也不易于判断其后续影响，往往只能是从上到下的逐一嘱托要求跟进等等，无助于问题的实质性解决。

       任务详细拆解这样的方式固然会便于管理，也有利于保障项目进度。但是，一方面在整体详细规划缺失、用户需求不明确的情况下，难以精准传达任务及解决策略；另一方面执行人员也非常容易在这样的规则下寻求庇护，当自身任务受到外界影响而延误的情况下，往往很难明确其责任。

       针对这类问题，建议在项目管理中，不必对在具体的交付质量上做过多的关注，这一部分自有甲方亲自解决；而是应当将更多的精力投入到团队间的衔接上，以及团队协同目标的制定上，确保每个团队的推进时都明白自身的对于其他团队的责任以及交付内容的具体要求。确保项目团队能够更好的协同推进，而不是头痛医头脚痛医脚。

4. 项目中没有明确产品上攻坚的目标

       在任务庞杂，需求模糊，工期紧迫的情况下，无可避免的导致在项目交付中会寻求外部资源的协助，尤其对于刚刚涉足智慧城市领域的公司来说，原有的积累不足，难以独自应对复杂的项目情况。以这样的模式推进项目，在项目完工总结时经常会发现，项目收获仅在于熟悉了EPC项目模式，在面对下一个新项目时，能够比较快的组织起团队，也对项目的交付有了一定经验，能够有效的保障项目完工，但是此前项目中辛苦开发的各类系统或内容服务进行复用，只是更熟练、更有经验的再一次完成项目，而没有获得在专业能力层面上的沉淀。

        在项目中GIS能力平台、大屏可视化渲染等方面是不严重依赖业务逻辑的，是每一个智慧城市项目都很有可能面对的问题，其实可以作为研发突破的一个方向。至于业务层面，所有事关流程的、习惯的需求应当视为定制需求，对此应采取履约完成即可的原则；然而一些有工具特征的，有简单但闭环的痛点支撑的需求反而在开发时予以关注，保障其使用体验、复用性、稳定性，未来的场景中如果有需求可以快速部署。

       基于这一逻辑，应该规避在业务层面，在业务交叉的内容上做太多投入，因为以上的这些功能全都是“带不走”的，在下一个项目、场景中无法复现，可以说投入的回报是非常低的，是不具有产品特点的。甚至可以说，眼下在EPC项目中逆流而上就是为了能够在这样的经历中淬炼出能够经得起市场、业务考验的产品。所以应当在EPC项目中明确参与的目的：绝不是将自己打造成一个专业的系统集成公司。

5. EIM产品难以成为项目主流；

       EIM产品固然可以和BIM/CIM有机结合，构建完成的数字孪生世界。但是就智慧城市项目而言，其重点必然是城市，植被在绝大多数情况下都不会是项目关注的重点。究其原因，第一因为城市中的植被品种相对单一，除市政部门养护外不需特殊关注，也就意味着不会有很多对口的单位进行相关项目的建设；第二植被生长不规律，在绝大多数情况下，如果要将植被进行高精度建模并呈现是得不偿失的；第三绝大多数需要负责植被养护的用户大概率也不需要关注植被具体的情况，相反可能更需要的是一套支撑养护业务的管理系统。

       智慧城市项目终究还是要服务到城市里的人才能真正创造价值，换言之在有大量人存在的场景往往就是智慧城市项目中有刚需的业务场景，例如交通、安防、5G及IOT设备等，而且这些业务场景往往能够获得政府持续稳定的订单，相应的也更易于培育出能够提供专业服务的产品、平台。

四、 智慧城市行业未来展望：

1. 互联网下半场；

       从当前的市场环境来看，确实具备了孕育大型2B/2G公司的条件。首先5G技术的快速普及对数字经济的繁荣奠定了基础，各类设备的发展则将智能化系统的普及变成了可能，同时政府的决策、施政也越来越依赖数据，所以在可预见的未来，各类型的智慧城市项目将越来越多，相关的基础设施的投资总量也将不断攀升。政府投资规模非常庞大，一个业务中的切实痛点就可能培育出该领域的专业公司，例如当前已经在监控-人脸识别领域已经出现了商汤、旷世等。在其他的业务痛点领域中，同样具备培育专业公司的机会。可以说智慧城市的涵盖范围有多大，其中的机会就有多广。

2. 以“数字孪生”为核心逻辑；

       为了便于对行业的未来发展趋势进行判断预测；或者对于一个方向、一个产品思路进行评价；又或者判断一项工作的价值和意义的时候可以借助这样一种思路：即是不是能够有效补充“数字孪生”中的缺失部分。例如，配色、布局、字体、样式等方面的需求都不是业务的核心需求，工作中应侧重如何提升满足定制化需求的效率。对于偏向业务流程的需求，则需要明确在哪些环节上可以有效获取缺失的有价值数据，而其他步骤或环节的设计上应尽量从简，因为所有的流程、步骤上的需求基本都可以笼统的判定为定制需求。最后，对于构思新的产品方向时，可以在既有资源、技术优势的角度出发，从现实世界中尚未数字化的内容入手，以业务中关键的数据内容为切入点，打造基础的服务组件。

3. 市场沉淀、方向分化

       市场经历了此前的割据与混战，各大公司都在逐步回归理性，力图将项目风险控制在自身的能力边界之内。个人判断，市场已经进入了沉淀期，由于系统建设所需要的连续性自然带来合作上的排他性，所以业内公司对各地项目机会仍然在努力争取，但总的来说各家已不在执着于合同金额，而是将目光聚焦在数据盘整、能力支撑、服务输出等方面。可以类比为“不再执着于做大厨，而是转变为顶级食材的提供者”，相信未来业内的各家公司都将提供各具特色的能力频谱。

      伴随着这种产品路线上的趋势性变化，智慧城市项目的模式也将出现相应的变化，简言之将从EPC向着SaaS模式转变。未来的产业格局，可能将变成由当地公司或者BAT等公司旗下的生态企业执行具体的交付和定制开发任务，而BAT等则专注于核心能力型产品的打造，形成头部公司提供具有专业化功能的SaaS平台，驻地团队提供专业人员依托平台提供服务的新业态。

      伴随着产品迭代进化模式的转变，未来智慧城市行业的模式也将相应发生转变，从以往的各自为战，依据自身需求量身打造系统；转变为获得行业认可的相关产品快速部署全国市场。也即从原来的客户导向转变为需求导向，以往侧重于为一个城市客户完成所有的开发任务，转变为为全国所有客户解决具有共同特征的共性需求问题。

4. 从“占山为王”到“开放共享”

       按照行政区划执行智慧城市项目本身就会导致割据的市场状态，加上系统开发过程相对封闭、缺乏行业规范标准指导，所以在初始阶段，智慧城市项目中孵化出的产品会呈现出丰富多彩的状态。虽然各大公司目前着眼的重点目标比较重叠，但未来随着专业度的提升，业务挖掘的深入，各家的产品功能将逐步产生分化，并最终提供各自擅长的专业服务，完成对市场的“圈地”。

       出于商业竞争、技术惯性、数据安全的原因，各公司间的数据势必将相互孤立，必然无法使数据在公司间自由流动。虽然数据原则上都将由政府用户掌握，但用户本身又被分为众多机关单位，所以数据的归集整理也问题重重，所以总的来说在各个地市的智慧城市项目往往难以避免重复建设，也无法将不同项目形成有效协同。

       从长远来看，以上的问题未来必将是行业发展的障碍，未来智慧城市领域经过沉淀盘整，这些问题都将浮出水面，相信政府部门也将出面对行业规范标准进行制定，由大数据局等部门出面统筹，将不同项目中生产、采购的GIS引擎、POI数据、BIM/CIM模型、高精地图、检测器及采集数据、服务器/网络资源等进行统一管理并筹划。未来的智慧城市产品，虽然运行是独立的，但是数据层面的输入和输出都必须是在政府制定的渠道中，以确保数据能够在不同的产品、平台、系统中自由流动，并在智慧城市的大场景中实现共享互通。

五、 市场切入角度及核心竞争力构建策略：

       目前大多数公司应该没有积累出丰富全面的产品体系，也没有构建自己的相关生态或参与到其他头部公司的生态中。所以目前想要涉足这个领域还是需要亲身参与各个环节的，那么目前的EPC项目总包模式就是最适宜当前阶段的模式。在承接的项目后，虽然往往力图将其打造为明星项目，但个人愚见项目的交付水准也是需要有经验支持的，所以不必苛求，关键是在项目中能够获得怎样的积累。

       如果试图打造试点并高水平交付项目，则交付团队规模往往都很可观。就当下来看，一方面项目难以获得盈余，另一方项目执行中也没有非常清晰明确的产品目标策略。所以如果坚定的要在这一领域进行探索，那么在EPC项目中实现收支平衡才是长久之计。为实现这一点，一方面需要争取更多项目，确保团队不停工，同时应当总结项目中大量耗散精力的环节在哪。一般来说，甲方内部缺乏规划、沟通导致的掣肘因素是最重要的原因，另一方面各级领导的个人好恶导致的频繁返工也是关键因素。针对以上问题，建议找有丰富项目交付经验的项目经理进行操盘，其主要职责一方面是对内明确交付内容和节奏，但更重要的是争取将需求等问题进行合理拦截，对需求进行有效管理。综上，对外控制项目工作量，对内承接类似的项目来提高团队复用率是当下的有益策略。

        后续团队能够在这种EPC的模式下稳定运营后，再分析项目间的共同性需求，针对最基础环节、最底层逻辑上的刚性需求，逐个逐次完成产品化的功能组件的开发，并且在未来形成公司自己的能力平台，进而形成产品+服务的模式。基于此，未来在承接新项目时，就可以对合作伙伴予以赋能，并从EPC模式中抽身。使公司自身专注于具有平台化、工具化的产品功能，并最终在智慧城市中获得一块儿稳固的阵地。