① 如何降低服务成本
服务最主要的是减员增效。当然一位降低成本必然会导致服务质量下降，所以提高服务的标准，提高服务质量，才能更有效挣钱。
② 如何有效控制服务成本
1、扣除法：确定企业的目标利润，然后再从产品销售价格中扣除应缴纳的产品销售税金和本单位目标利润，其余额就是需要努力实现的目标成本。
2、经验估算法，也叫调查研究法：是对同样产品，采取同行业先进企业以及本企业的历史先进水平或上年度的实际成本，结合在计划期内各种变化的因素进行分析研究，根据预测成本降低的可能性及其保证程度，估算出产品目标成本。
3、高低点法：根据成本习性将企业成本分为固定成本和变动成本，用一定时期历史资料的最高业务量与最低业务量的总成本之差与两者业务量之差进行对比，先求出单位变动成本，然后再求得固定成本总额的方法。
控制服务成本注意事项
传统的成本降低基本是通过成本的节省来实现的，即力求在工作现场不浪费资源和改进工作方式以节约成本将发生的成本支出，主要方法有节约能耗、防止事故、以招标方式采购原材料或设备，是企业的一种战术的改进，属于降低成本的一种初级形态。
高级形态的成本降低需要企业在产品的开发、设计阶段，通过重组生产流程，来避免不必要的生产环节，达到成本管理控制的目的，是一种高级的战略上的变革。
以上内容参考人民网-坚决落实过紧日子要求 严格控制机关运行成本
③ 微服务的主要优势有哪些
1.将复杂的业务拆分成多个小的业务,每个业务拆分成一个服务,将复杂的问题简单化。利于分工,降低新人的学习成本。
2.微服务应用的一个最大的优点是,它们往往比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来,开发人员只需要为额外的组件部署计算资源,而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其它任务。
3.微服务应用程序的另一个好处是,它们更快且更容易更新。当开发者对一个传统的单体应用程序进行变更时,他们必须做详细的QA测试,以确保变更不会影响其他特性或功能。但有了微服务,开发者可以更新应用程序的单个组件,而不会影响其他的部分。测试微服务应用程序仍然是必需的,但它更容易识别和隔离问题,从而加快开发速度并支持DevOps和持续应用程序开发。
4.微服务架构有助于新兴的云服务,如事件驱动计算。类似AWS Lambda这样的功能让开发人员能够编写代码处于休眠状态,直到应用程序事件触发。事件处理时才需要使用计算资源，而企业只需要为每次事件,而不是固定数目的计算实例支付。
缺点1.整体复杂度更高,微服务根本上说是一个分布式系统。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。虽然这个有很多框架可供选择,并不需要从头实现。但是整体上的代码复杂度是提高了。
2.微服务架构上每个业务有自己的数据库。以前在单体应用中很好解决的事务问题,现在变得很困难。在基于微服务的应用程序中,需要更新不同服务所用的数据库,通常不会选择分布式事务,不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理,最后不得不使用基于最终一致性的方法,这对于开发人员来说更具挑战性。
3.测试微服务应用程序也很复杂。例如,使用 Spring Boot,我只需要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下,一个类似的测试类对于微服务来说需要启动该服务及其所依赖的所有服务,或者至少要做服务mock,虽然这不是一件高深的事情,但不要低估了这多出来的工作量和复杂度。
④ 浅谈对微服务的一些思考
两年前，第一次真正接触微服务的概念，但也只是简单地进行了使用，当时技术栈主要是 Spring Boot,那时 Spring Cloud 也比较流行，但是由于各种原因，并没有转向这套（甚至用 zookeeper 实现了简单的服务发现），理论上来说，用了 Spring Boot 再转向 Spring Cloud 应该是很正常的事情。当时也认为 Spring Cloud 各种理念很高级，实现上也不错，也有 Netflix 等之类的大公司背书，而且和 Spring 天然集成的，使用起来还是比较方便。当时可能觉得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比简直差了一个档次，可能大家都认为 Spring Cloud 是未来。
从第一家公司离职后，去了另外一家公司，发现一个很奇怪的特点，这家公司的技术比较保守，基本还是十年前或者五六年前的技术架构。记得之前看过一本书上说过，技术不与时俱进，那就相当于自取灭亡，特别是技术驱动型公司，如果一直停滞不前，那就相当于你拿几十年前的武器和别人战斗，那结果自然是必然的。为什么技术要与时俱进，不是因为有了新技术就要去使用它，而是因为新技术往往可以提高业务的运转效率，同时也可以降低成本。不过在这个公司待了两个月，还是觉得有可取的地方，第一点是对代码质量的追求，由于业务的体量和特殊性（大概是亿级），所以对代码有较高的要求；第二点是对微服务整体架构的深入，虽然这个系统没有上 Spring Cloud ,甚至 Spring Boot 都没有，还是很老的一个架构，但其中微服务的思想已经有了，比如服务的拆分，服务的水平扩展，基于 Dubbo 的一些服务发现和治理，整体来说已经算是不错了，但是也总在思考，感觉还是少了什么东西。
容器化和 CI/CD
后来又到了一家比较年轻活跃的公司，接触到 Docker 的大规模使用以及 CI/CD，也是在这里，形成了整个对微服务完整生命周期的理解。 Docker 其实流行也很久了， 但是真正线上使用的并没有那么多，最近随着 Kubernetes（ k8s ） 的流行，更多公司也开始关注起来。
首先为什么服务要容器化，第一点是不再依赖于运行环境，只要有 Docker 就可以跑起来，无论你是什么发行版的 Linux 系统，还是 Windows，Mac。这有点像 JVM，屏蔽底层的细节，一次编写，到处运行，用在容器上就是一次构建，到处运行。第二点是容器化可以更好的进行持续集成，由于第一点的缘故，部署一个服务容器将非常快捷，这更加适合目前 devops 的理念。
持续集成(Continuous Integration)简称 CI ,持续部署（Continuous Deployment)简称 CD,如果微服务不把 CI/CD 放在首位，那必然整个流程就是不流畅的。有些公司还是手动本地构建包，然后 上传 到服务器上跑起来，进行这样的人肉运维，人肉上线，要么考虑一下，是不是整个 CI/CD 有问题，或者根本就没有 CI/CD 。其次 CI/CD 流程要做到每次构建自动跑单元测试，集成测试，以及 API 测试，UI 测试等等，这些流程也没有自动化的话，也谈不上完整的 CI/CD。如果没有经过这些流程把包直接上传到服务器，不出问题，那应该要烧柱香，拜拜佛。
云原生应用和服务网格
云原生应用遵循 Twelve-Factor ，云原生应用是为了解决传统应用发布升级流程缓慢、架构复杂，可维护性差而提出的的一个思想集合，集中了 微服务，devops，云等多种思想。
云原生应用应用可以跑在任意一家云服务商上，也可以实现多家服务商同时使用，同时也支持公有云和私有云的混合部署，这只是它的一个特点，更多的特点还是集中在解决传统应用面临的问题，如灰度发布，不停机发布，A/B Test, 快速回滚，服务治理等。
服务网格（Service Mesh）是一个比较新的概念，但是核心思想并不新。Spring Cloud 以框架的形式侵入到程序中来解决微服务的各种问题，理论上来说，应该是效率最高，最灵活的一种做法。但是侵入性太强，而且只能 Spring 这套，异构语言的系统玩不转。Service Mesh 从另外一个角度来解决这个问题，也就是 sidecar 和 proxy，这样虽然性能上有些损失，但是扩展性却是比较灵活的，将这些基础能力（服务发现，服务治理，熔断限流，监控等）下放到基础设施中，做到对应用程序透明，是一个不错的进步。写业务逻辑不需要再去和这些东西纠结，代码逻辑也变得十分明朗。同时这样也解决了异构语言系统的问题，无论什么语言，都是可以完美的工作在一起，简直是一个完美世界。但是但是但是 Service Mesh 由于还比较新，目前还不能进行生产环境使用，就拿目前最流行的 Istio 来说，目前只发布了 0.8 版本，还不能实际使用，估计 1.0 也不行，可能得 1.2 才推荐生产，所以现在就面临一个困境，Service Mesh 是一个好东西，但是我们却用不了，呜呼哀哉。
Spring Cloud 和 Service Mesh
首先两者解决问题的方式不一样，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，这可能会造就两者之后的命运。如果目前已经上了 Spring Cloud 或者其他的，系统已经具有基础的服务治理能力，先不要考虑 Service Mesh ，要先去考虑容器化和 CI/CD ；如果没有太多的 历史 负担，则是可以考虑。
总结
技术发展太快，不能停滞不前，也不能盲目追风。当年的 SSH 也只剩下了 Spring，可是有人说 Spring 只能一个季节用，但是 Service Mesh 整年都可以用，好像很有道理。最后，路漫漫而修远兮，吾将上下而求索。
⑤ 微服务是如何演变的，又为什么重要
微服务的概念产生是顺应这样的需求：为了开发出速度更快、更有弹性且用户体验更佳的应用。这个概念等同于具有可扩展性的自动化系统，在简单的商业化架构上运行软件。由于容器所提供的经济效率，在2016年微服务将是一大主题。
应用快速开发的需求影响到了全部公司，以及如何看待历来业务安排的方式。来自微服务的新实践代表着需要小型团队以对于公司来说陌生的方式——自上而下进行迭代。这意味着企业运作的方式将获得彻底的改变。
现在在针对应用架构与微服务的新思考方面，容器生态系统逐渐成为核心主题。根据Battery Ventures技术人员Adrian Cockcroft的说法：关于微服务有一些基本的原则需要思考。首先，如今构建软件的价格更为低廉，容器的出现降低了成本。Docker被所有人纳入蓝图——从软件供应商到终端用户，所有人都在尝试找出容器的用法，因为用它就能加快软件的交付节奏。不过这也代表着要安装的系统是应用级别的，也就是说在应用的开发、部署与管理方面出现了不同的需求。
Adrian Cockcroft在面向对象软件架构大会上关于微服务的演讲，以卡通形式呈现，作者是Remarker
举个例子，对于要处理服务与堆栈范围增长的公司来说，监控比以往更加重要。要想解决问题，必须对数据日志进行分析，而这些日志很可能横跨临时节点与多项服务。由于需要细化监控与加强工具，从业人员能更好地掌握这些构建模块对于应用所依赖的许多潜在微服务的影响。
那么起作用的是什么呢？从公司与API开始：基于微服务的产品团队与另一个基于终端的平台团队之间靠API连接，通过API调用以及企业基础架构持续作出相应的回应来生效。
微服务被定义为特定背景下松耦合、面向服务的架构，允许在无需理解其他部件运作原理的情况下进行更新。整个服务是跨公司构建的，但所有权却在同一个地方。微服务架构提供了更多系统间的点对点调用。消息形式必须灵活，所有部件在无论哪个版本中都能运作。这意味着在构建微服务架构时，我们需要一些工具来配置、探索、输送流量、观察与构建系统。
IBM杰出的工程师兼IBM云计算中心的CTO Andrew Hately作出了类比：15年前人们可能需要每周查看一下自己的银行余额，而互联网允许人们实时查看余额甚至做出进一步操作，也许随着智能手机的发展，很多事情都发生的改变。如今，人们可以即时访问自己的账户收支信息。这种速度与即时性代表着：在过去的5-10年内，企业提供服务的发展速度必须跟得上社交网络与搜索公司发展的速度。
公司必须处理员工、消费者、系统与所有可能组合之间的持续互动——就像Hately所说的完全互联与持续可用。这意味着企业流程需要重建，需要将所有东西连接起来。如果公司不进行这方面的尝试，也无法提供相应功能的话，很快就会面临收入减少甚至出局的局面。
Hately表示：“工具非常关键。” 有数百家网站不支持代码，收到反馈后，在下一组测试用例中消费者就能使用它了。这种严格的开发过程提供了一种企业工作方式，也为微服务发展提供了思考方式。DevOps中的ops也会执行这样的工作。如果你有一小段代码并为其定义指标的话，就能细分出哪些会成功，哪些会失败。
IBM通过为消费者及内部团队构建反馈通道与成功标准，在敏捷、DevOps、精益生产与其他迭代进程中结合最佳实践，创建了名为IBM Bluemix Garage Method方法的企业方法论。IBM Bluemix Garage Method方法将企业解决方案的可靠性及可测试性与最新开放社区在规模质量上的最佳实践结合起来，持续创新、创建持续交付渠道并在云平台上进行部署。这种方法很有价值，向所有人开放资源能够提高个人、团队与全公司的DevOps技能，以及管理与监控能力。
软件相关的契约
第一代的容器管理平台支持这些速度更快的开发进程。Docker的产品高级VP Scott Johnston表示，在Docker Compose中，微服务促进了工具发展，YAML文件扮演了描述不同组件的清单（manifest）。Compose让开发人员得以用抽象的方式描述多容器应用，它可以描述web容器、数据库容器、负载均衡及其间的逻辑关系，无需连网或部署存储。
Engine Yard的Matt Butcher表示：微服务是软件相关的契约。有些人会辩称微服务是正确执行的面向服务架构（SOA）。开发者想要的是有用、功能丰富且结构优雅的架构。微服务使得软件开发回归Unix的根源——将一件事完成得很好。用Unix可以任意输出命令。微服务不止在如何优秀地完成工作方面，同时在如何与环境互动方面也表现出契约性。如果运行良好，它所做的工作就像是优秀的Unix shell脚本。
举个例子，Kubernetes清单文件格式扮演着契约的角色，这个清单提供了所需的来源细节、存储卷定义、存储需求等，扮演了强大的DevOps类契约。它让开发者和运营者了解想要的内容。开发者与运营者之间的关系不再如同之前那样——开发者被迫只管自己的一摊工作。
一张清单可能会包括应用元数据，加上具体版本的描述性参数，其中可能还有多个清单。也许是一个实例、一个pod清单、一个复制控制器（replication controller）或者一个服务定义，还有组成文件的已知来源位置。任意标签可能由图表中所包括的组件来定义。
Butcher表示：“应用开发者在这方面的体验够深刻了。一旦出现典型问题，就会说丢过墙去，各管各的，反正有DevOps来负责生产环境中的运行事宜，开发者只负责开发，总有一个切换过程，往往会成为各扫门前雪的后果。”
如果开发者构建容器，会存在一定的水平保证（由抽象层决定）：这些容器的运行方式在生产阶段与开发阶段是一样的。这已经缓解了让懂得容器这个基本工具的DevOps专业人员感到头疼的大多问题。容器化已经提供了这种保障，不过像Helm（Engine Yard所提供的新服务）之类的产品有助于进一步规范化这种关系，具体表现为团队间的契约形式——团队成员不能再推卸责任，各扫门前雪了，而要全程参与。
从虚拟机与Monolith，到容器，再到微服务
根据Joyent的CTO Bryan Cantrill的说法：容器为原生云架构提供了基础，与传统的虚拟化形式相比，象征着一种新的应用架构形式。在使用较大的机器来进行计算时，基于硬件的虚拟化或者传统虚拟机流行过一段时间。虚拟机为运营团队提供了管理大型整体应用的方式，就像Cantrill说的“过于臃肿”，而硬件定义了企业架构。虚拟机建议在底层之上，承担了运营系统的负载。但是容器创建了一个全新而更敏捷的抽象。就是Cantrill的那句话：“应用继续减肥速成修炼。”
如今，唯一的麻烦在于如何将虚拟机和monolith换成容器和微服务。各家公司还在想方设法执行这种转变，因为两种方式对应用架构、基础设施还有公司自身整体的思路都是迥异的。
Cantrill表示：Joyent的开源Triton服务，其目的就是为了简化与加速公司向容器与微服务的转变。它允许开发者简化架构，只提供容器，不提供虚拟机。由于无需配置网络等操作，用户可以通过阅读微服务手册，在短时间内完成部署。
Cantrill表示，Joyent公司是Docker Compose的粉丝，因为Compose可以用来与单独的Docker Engine通讯。Docker的远程端点由Triton部署，从而虚拟化了整个数据中心。使用这些工具，很容易快速让一个完整有弹性的运营服务运转起来。正如Cantrill所言：“这是大势所趋。”
VMware的CTO Kit Colbert从如何沿着容器之旅前进的角度来观察市场。VMware着重运营领域。现在它开发了一种方式，来满足新的开发人员及其需求，不过是作为基础架构提供商存在。
对于VMware来说，这家公司将自己视为基础设施提供商，而不是以应用为中心、面向架构的公司。Colbert只看到了对Cloud Foundry感兴趣的消费者，不过也有人想要DIY的方法。VMware正在设法通过vSphere集成容器（VIC）与Photon平台对应用技术提供支持。
为了让消费者适应使用容器，vSphere集成容器（VIC）让容器化工作负载称为vSphere的重中之重。VIC适合在开发进程中运行，将容器化最有价值的一个方面应用在容器中：灵活并具有动态的资源界限。通过虚拟化，VMware将普通硬件转化为简单、可取代的财产。同样，通过在虚拟机中应用Docker端点，vSphere集成容器创建了完全动态边界的虚拟容器主机。结果就是对传统与基于微服务应用同样支持的基础架构，允许IT与开发者的访问。
相比之下，VMware的Photon平台是专为原生云应用设计的。Photon平台由最小的管理程序与控制面板组成，专为微服务提供速度与规模的服务。Photon平台在设计时还考虑到了开发者通过API使用时的易用性，让这个平台成为一个提供应用程序与快速部署的自助服务平台。
从VMware的角度来说，运营团队也在推进部署速度。现在更着重于数字化体验或者软件如何提供更多功能方面。很类似我们如何看待在智能手机上使用的应用。供应商可能以声音很大的扬声器而闻名，不过服务的应用是否能提供功能？
Colbert询问：“我能依赖它吗？” 公司必须找出构建应用，为寻找高质量应用的消费者提供服务的方式。想要继续进步，就必须找到这一点。很多拥有外置式、虚拟化基础架构的消费者希望：随着应用开发进程的加快，解决公司面临的挑战。
在微服务时代的开发
软件开发是迭代式的，需要持续的反馈循环才能奏效。这也是类似IBM Bluemix Garage Method所提供的工具所提供的功能。不过大多公司是根据模型来执行的，这与开发者工作的方式不同。开发者不会按照销售、市场推广、财务等部门人员的方式来工作，开发者不是按照计划或方案来执行工作的。软件开发的过程有更多的迭代，并非瀑布式自上而下的。
Pivotal的首席技术Michael Coté表示：“我不知道怎么说，不过真实世界与软件世界是完全不同的。”Coté辩称：找出软件开发的方式似乎非常矛盾，不过事实上确实阻止了人们想要根据一份文档来了解一个巨大机器的所有部件的工作方式。通过遵守软件开发的原则，各家公司找到了自己的办法，而不是严格遵守固定的计划。
Coté认为，没有执行微服务的固定道路。用微服务可以在运行中和架构上获得灵活性。微服务根据简单的原则构建出真正复杂的东西。原则越简单，所能创造的东西就越复杂。
不过，如果把复杂性转移到其他地方会发生什么？Pivotal这个平台管理着复杂程度。去掉选择，让消费者无需考虑网络、运营系统等问题。它允许消费者将复杂性放在应用堆栈的顶层，在为终端用户提供服务时能够更好的区分服务。Hately表示：“在科技行业，我们看到了另一个文艺复兴时期。”
同样地，IBM Bluemix Garage Method也希望简化复杂性，以便让开发者的工作更有效率，能够更好地享受自己的工作。所有这些努力都为企业提供了巨大的机会，无论在技术还是文化层面。
⑥ 企业服务如何降低获客成本
近两年，做企业服务的公司越来越多，获客成本也越来越高。就拿网络推广来说，我之前为朋友的一家公司做了两年，总结了以下几方面经验，仅供参考！
一、开通网络竞价推广
做网络推广其实是一个比较烧钱的方式，但是制定合理的推广策略，精准地控制好推广成本，也是可有效地降低获客成本。有些公司招聘专职人员来做网络推广，是没问题的，但前提是所招聘的人员要有足够的推广经验，否则也会造成较多的资金浪费。
二、做好搜索引擎优化
搜索引擎优化也叫SEO，SEO在最近几年里越来越难做出效果，主要是由于网络搜索引擎算法不断迭代以及行业竞争等因素导致。我为这位朋友策划了50000+页面量级的网站，听起来有点不现实，但是这么做，SEO效果真的不错。SEO做了一年半的时间后，SEM推广成本又降低了40%，这样下来，就等于降低了获客成本。
⑦ 简述o2o模式是如何降低顾客总成本
1、降低了顾客寻找的时间成本，利用lbs可以快速引导客户到线下所要去的地方
2、通过预约，节省了顾客等待的时间成本
3、通过网上展示，节省了顾客了解产品的成本
4、通过大数据，就近配送和就近库存，降低了产品的运营成本
⑧ 如何降低客户服务成本
降低客服服务成本，除了培养一个好的客服人员，还要销售人员的专业和不盲目、不夸大销售。销售人员最好销售公司能做到的服务和产品，这是降低客服服务成本的重点之一。
⑨ 小微企业如何有效降低成本
企业在发展过程中总会遇到瓶颈，觉得运营成本高涨，却又难以找到成本的所在，我们称之为“隐形成本”。这如同生命体暗藏的疾病，久治不愈，挥之不去，让经营者颇为头疼。
一、会议成本
会议是企业解决问题和发布指令的集体活动，但是也是一个高成本的经营活动。因为这个活动往往是很多领导者参与的集体活动，每过一分钟，意味着与会人员总数的分钟数，而很多企业的管理人员并未掌握开会的技巧，都存在“会前无准备，会中无主题，会后无执行，与会无必要，时间无控制，发言无边际”的六无现象。
当每个月发放薪水和总结收入时，财务报表的数字总是成为经营者奇效的“失眠药”，殊不知这颗“药”的很大一部分成分就是会议。
二、采购成本
采购在不同公司有不同的方式，但这是影响企业经营的重要成本。我们常常只会将此成本关注在采购的价格和数量上，而难以看到除此之外的其他因素。
曾经有一家企业，在做一个新项目时，项目组每天的运营成本为8万元，可是其在产品上市前夕，采购部门为了采购10万余元的包装，竟然耗费了一周时间，理由是要找价格低廉的供应商以节约采购成本。整个营销团队因此多等待一周时间无法和客户签约。
而这种现象其实在很多企业里均存在。一味的追求降低采购的直接成本而忽略了同时并存的“隐形成本”。当然，降低采购直接成本与本文并无冲突，在这里，我们要说的是企业的采购部门，要站在整体经营的角度综合权衡的各项指标，才能真正控制采购的成本支出。
三、沟通成本
沟通，是企业运营的重要环节，很多企业在做众多的制度培训，精神层面的培训，可是大多没有“沟通能力”培训。
在大多数企业，你会发现，在同事之间的沟通过程中，会出现严重失真的现象，或词不达意，或答非所问，或百人百解……这种现象，说小了，让很多工序成为无效工序，或失去很多重要机会。说大了，有可能因此给企业带来隐患。
四、加班隐患
加班成本很多老板总认为，员工在下班后“废寝忘食”的“加班”是一种敬业现象。殊不知，这可能隐含着很高的成本。理由有三：
第一，加班的原因并不一定是因为工作任务太重，而是员工的工作效率低下造成的，加班意味着低效率。
第二，加班耗费更多的员工精力和体力，严重透支员工的健康，长期下去，会让一些重要员工不能长期发挥其效能，并且有为公司带来负担的隐患，比如有的机械操作员工因为长时间加班而导致疲累，造成事故，而企业要为此付出沉重代价。
第三，加班员工并不一定“务正业”，有些员工在下班之余，名为加班，利用公司的资源，从事其个人事情，同时还领取公司的加班费，很多企业的重要损失、数据丢失等都发生在下班时间，而加班成为企业“藏污纳垢”的死角。
五、人才流动成本
有很多企业在人力资源管理上都是很欠缺的，他们认为人才是无限的，成为“铁打的营盘”，员工自然也就成为了那“流水的兵”了。不能不说，一个员工的离开对公司都是一笔成本，因为公司要承担对这个员工的培训费等前期投入，还要承担新招聘该岗位员工的前期成本，还要承担新员工是否适合岗位的风险，而老员工的离 职也会因为职业素养的关系，可能会流失重要的内部资料或信息，而其离职后，很可能会进入自己的竞争对手的企业。
所以，员工特别是老员工的流失无疑会给企业带来高出其收入几倍的支出。很多小企业在经营多年后，你发现他们一直是那么小的团队，而除了老板之外，没有一个员工是从企业成立当初留下来的。
六、岗位错位成本
人力资源管理中有句名言“将正确的人放到正确的位置”。可惜，真能做到这点的企业的真的不多。
曾经在一家人才市场招聘，听到其员工之间的谈话，说每次招聘会都要他们全体职员去搬桌子和椅子，因为是租借的体育馆作为招聘场地。上到职业经理人，下到普通职员，都成为了“搬运工”，我不禁叹息，这家企业从事的是人才招聘与管理，怎么会花那么高工资请来并不专业的搬运工。
其实这体现了老板们一个非常清晰的心理，他们认为这些员工招聘回来就是要用的，只要自己有人手能做的，就不用再花更多的钱去做。但是我们发现他们因此付出的代价很高。该企业的员工一直抱怨不停，因为相当多的都是女职员，根本没有力气搬运桌椅，那些高官们也从来没有经受过这等“礼遇”，有些纷纷离职。我们也 从此不在该招聘会招聘，因为我不相信这样的团队能给我提供很好的服务。
七、流程成本
企业的乱，有太多都是因为流程，这在企业管理中是一个通病，凡是发展缓慢的企业，其流程一定是混乱或不合理。他们为此承担着很高的成本，然而一直却视而不见。流程，是企业运营的产业链，如同流水线一样，没有科学合理的流程，也就失去对各项工作系统性的控制，很多工作半途而废，还有很多工作需要返工，无奇不 有。这会成为裹住企业前进双脚的乱麻。
八、停滞资源成本
停滞的资源在企业里可以说是最广泛的“隐形成本”，例如闲置的设备，积压的库存，低利用率的岗位职业，闲置的资金、搁置的业务等，他们虽然不一定会继续消耗企业的投入，但是他们却是企业资产的一部分，企业会为此承担着利息等隐形成本。所以说，一个企业里，停滞资源的多少，体现着企业资源利用率的高低。
九、企业文化成本
有人说企业文化如同一个企业的魂，会在其每一个成员的精神面貌中得以体现。这种文化在企业成立的初期阶段就开始建立，他受企业的创始人的文化、习惯、技能、职业、好恶等影响，因此有人说，企业文化就是老板文化。
但是说企业文化会成为成本，或许很多人不以为然，但事实如此。我们会发现一些企业的员工精神萎靡，做事效率极其低下，无论多么优秀的员工只要进入，不久要么离开，要么也会变成那样，我们不能不说，这是“环境”问题。而这个“环境”正是这个企业的企业文化。
企业文化如同企业的生命，会伴随企业的一生，只能调整，无法重造。
十、信用成本
这是一个牵扯到远期回报的成本，诚信经营如同诚信做人。我们发现，很多企业，习惯拖欠供应商货款，习惯拖欠员工薪资，习惯克扣他人，习惯拖欠银行贷款等等，认为这样可以减轻企业流动资金压力。
但是从长远来看，这会成为企业经营的严重隐形成本，首先，供应商一定会将时间成本算在其报价中，这类企业无法采购到最低价格的原料或服务。其次，员工薪资拖欠，违背劳动法规，有被惩罚的危险。而拖欠银行贷款，克扣他人，会给其信用度大打折扣，在企业某一天遇到困难时，会四面楚歌的。无疑，企业为此要付出惨 重的代价，而其实其并没有因此获得任何益处。
十一、风险成本
将企业推向快车道是每个企业家的梦想。但是风险系数也因此而同步增加。特别是大中型企业，他们虽然发展迅猛，收入丰厚，但是一旦出现危机，将是灾难性的。多个案例证明，企业的风险很多都是因为预料不足或管理不善造成的，在风险发生前，都早已埋下隐患。而很多大型企业或者知名企业因为一次风险而消亡。
可见，风险是举足轻重的隐形成本。而这种现象并非显而易见，实在是“不鸣则已，一鸣惊人”。
十二、企业家成本
“企业家成本”是指的是企业的老板本身给企业带来的成本。有一句话说的好，兵熊熊一个，将熊熊一窝。企业家如同一支军队的首领，其本身是企业支付成本最高的员工。很多民营企业的老板把自己变成了企业的“皇帝”，一切自己说了算，全体员工变成了执行的机器。但是，企业家个人因素的缺陷，将会为企业增加沉重的 成本负担。
这种现象主要体现在小型企业，但在大型企业里也存在着这样的现象，我们也可以将这种成本延伸到企业的每一个部门甚至是每一个职员。因为每个人都要为自己的工作负责，我们常常强调，在你的范围，你就是领导，你有权决策。而很多领导者一直以自己为中心，这将大大降低了团队的作战能力，增加了高额的隐形成本。记 得曾经对一个抱怨公司缺乏人才的老板说过一句话：“你们公司缺乏的不是人才，而是发现和善用人才的智慧”。