微博时代的企业公关危机特征研究

 


        在以云计算为基础的数据库时代，原来的信息消费者变成了信息生产者。不良的信息对企业的生产发展常带带来致命一击。微博时代，企业信息披露呈现以下4大特征：



1、传播速度快
        在以云计算为基础的数据库时代，原来的信息消费者变成了信息生产者。微博传播新闻的速度以分、秒计算，不再像传统的媒体，以纸介媒体和电视媒体作为信息的主要途径；在开放的网络平台上，任何用户的发言都增加了新闻的扩散速度和影响力。使得企业危机出现得越来越多，突发性越来越强，危害性越来越大，传播速度也越来越快。传播速度快，是企业信息公布不当而致使发生公关危机的重要因素。


2、大众化趋势明显
        微博时代，互联网逐步发展到个人互联，为网络使用者提供了“出声”的话筒，并可以与媒体互动，由传统的媒体推动，演变为民众推动。大众可以第一时间将信息用生活化的语言，迅速传递到用户所在的圈子，甚至比网络在线新闻、新闻播报更快、更大众化。


3、更喜闻乐见
        相对于官方新闻、报纸、网络评论，呆板、劣拙的新闻文辞，140字的微博发布者即兴成段、脱指而出，更易形成碎片化的文字传播。同时由民众即兴调侃而盛行的各种“门”、“钓鱼”、“藏猫猫”等贴近大众生活的口语，更易激起大家的好奇心和新鲜感，让他们更热衷于参与传播、关注和评论，引发消息的进一步扩散。一旦不良信息被冠以一个有传播趣味的名字或一段风趣成章的片段，在很长时间内，都非常容易被搜索到，并可能一直存在于网络中。甚至，也许只要输入该企业或产品的关键词，相关被热炒的流行语就会在搜索引擎的引导下直接成为搜索结果，长期影响企业形象。


4、破坏性更强
        大部分网络用户缺乏正统、规范的新闻媒体专业培训和锻炼，往往情绪化的传播不负责的新闻信息，并带有极强的感情色彩抨击评论，容易引起极端反应。更有甚者，谣言来于内部：企业内部员工对企业有不满，以及一旦有大众关注的其他小道消息传来，他们都可能把信息在第一时间内便捷地发到网络上。若其他媒体推波助澜，信息经过各种途径受众数量的数倍扩大，企业就很可能成为“网络公民”口诛笔伐的对象，企业在事件不断的发展、移动、演变中，若应对不妥，引发多次信任危机，造成“一着不慎满盘皆输”的局部。

未雨绸缪 企业危机公关策略解读 
 

    文 何斌修
 
　　危机公关是衡量企业公关综合实力的标准，也是任何企业的立足之基、发展之本。危机如火，但灭火的重点不仅仅在灭火本身，还需要关注灭火前、灭火中和灭火后的全过程。
 
　　防患未然  
 
 
　　企业的危机好比“飞来之祸”，随时随地都可能暗藏着。但危机的出现，大多都是有预兆的。一些企业是等到危机无法收拾的时候才出面调停，但往往大势已去，难以扭转乾坤，那么怎样来避免危机呢？
 
　　建立媒介关系
 
　　企业要做到乐意和媒体打交道。要奉行四海媒体皆是客的待媒体之道，这样不但能深受媒体朋友的好评，更重要的是会给企业结交更多善缘。建立在这种良好关系的基础上，圈内只要有风吹草动，企业都能运筹帷幄，从容面对。
 
　　保持媒介沟通 
 
　　企业特别是大企业应该组建公关部门，并把和媒体的沟通定为一种经常性工作。因为与各媒体沟通不但能碰撞出“火花”，更能寻找出方法与资源。如果经常和媒体沟通，所有不利或者有利的公关素材必然就会显现面前，使企业能洞烛机先，防患未然。企业的危机绝对不是偶然现象，之所以一些危机发展到不可收拾的地步，都是对此苗头的危害性和爆发性预测不足。虽然很多企业能及时进行危机公关，但这显然是下下之策，为什么我们不能防患未然呢？
 
　　悉心研究传媒
 
　　企业要自觉地承担一项重要任务，就是在广大媒体群落中搜集一切企业和行业的相关信息，将信息进行分类整理，并分析与研究，从而为广告和企业宣传及公关方案奠定基础。众所周知，大多数危机的产生都是因为变化使许多人受到了利益伤害，但这种伤害产生的矛盾冲突最容易被当事人告知媒体，或者被媒体察觉到。所以企业一定要紧盯行业的政策变化与企业的事件变化，会给哪些人带来了利益损失，然后进行有效处置，将内外矛盾尽可能减到最低。所以公关部门应该一直坚持把内外行业信息汇编成册，并提供专业分析，提供一套强有力的预警措施。
 
　　危机攻略
 
　　危机公关借助的是沟通的力量，只要将所有的问题定位在沟通上，对面临的问题有一个全面、系统的把握，那么公关部门就有可能用最低的成本来消除危机。
 
　　评估危机 
 
　　任何一次危机的发生，当事人或消费者都有过激的反应，不可能都按照企业的意思理解。所以危机公关的一个重要原则，就是了解公众，倾听别人的意见，确保企业能把握公众的抱怨情绪，并做出准确的判断。不管事态发展如何严重，只要有准确的评估，根据评估的结果，就能衡量其危害性制定相应的策略。
 
　　直面危机
 
　　危机公关中要时刻遵循互动性、谅解性、真诚性的原则。当危机出现的时候千万不要惊慌，首要的问题就是赶快成立危机公关团队，并把握住宣传口径的一致，以免给媒体和大众落下口实。在处理危机时一定要有礼有节，不失形象，以防止个别消费者以此事件为突破口进行动机不良的行为，给企业造成更大的损失。同时要适时采取果断、正确的处理措施，及时与产生危机的消费者进行良好沟通，同时邀请报道此事件的媒体全程跟踪采访。其次处理危机过程中一直要保持态度良好。哪怕责任不在企业，都要留有余地，以免引起消费者误解，要体现企业的大度。因为如果企业声明中没有一种良好的公众态度，很容易令消费者误解并给企业埋藏下更大危机，进一步加大对立面。
 
　　巧妙应对
 
　　在取得与消费者、公众及媒体良好的沟通交流后，巧妙制定危机公关策略，分步骤地实施危机处理，对所有的危机处理办法都应该采取尽快的解决方案，这是处理危机的最高宗旨。
 
　　可以说，危机不管发生到什么程度，公关的根本办法仍然是从寻找源头开始，如寻找到消费者及曝光媒体。只有寻找到危机源头才能将危机处理在萌芽状态，找到了源头的处理方法也很多，但是目的只有一个，就是控制源头或者堵住源头。
 
　　如在接到事主投诉时，要及时安抚事主，并与事主进行一系列耐心的沟通，充分表达企业是充满爱心与责任感的，从而从根源上对危机进行化解。如果一些媒体已经刊登出相关报道，给企业造成了不良影响，公关部门一定要说服此媒体进行跟踪报道，比如以广告形式或者新闻形式进行追踪链接。这样，前期报道的影响无形中就会被瓦解了。 
 
　　利用局势
 
　　只要有危机的产生，多少会对企业和品牌造成一定的负面影响。企业除了处理好公关危机，还要做好善后事宜，如恢复消费者、社会、政府对企业的信任。
 
　　借着前期社会关注较高的机会，企业可以加大在当地主流媒体进行品牌形象和企业形象的宣传，让更多的人知道并了解企业是一家非常有实力、非常有社会责任感的企业，这可以从实力展现、公益活动、用户反馈、企业研发等多角度报道宣传。并可以迅速策划一个与消费者相吻合的互动参与活动，这个参与活动的主要对象就是前期购买了产品的用户和当初参与报道的媒体，以及刚刚购买新品的用户。让他们进一步感受企业的认真、负责和对他们的关心，从而形成延续性的良好口碑效应。此种宣传不但可以对已经造成的影响做观念扭转，同时这种公关报道也对扭转传媒方向和稀释前期不利报道起到了很好的作用，更能体现企业公关部门的老到。 
 
　　其实，只要平时工作到位，当危机产生的时候，最高招术还是立即利用手中的媒体资源让其保持沉默。 
 
=======================
 
  今天是我来公司近两年时间第一次参与公司的公关危机处理，虽然只是一件小事，但至少使的我开始对相关的内容有了一些了解，同时也去找了一篇资料，供自己学习与参考。

    对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。
 
       对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。
 
       面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。
 
       让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。
 
       当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。
  
 　　如果打开你最近的程序，看看DAL代码，你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例，你传入一个对象，为SqlCommand对象添加SqlParameter，把所有属性和对象对应，设置SqlCommand的CommandText属性为存储过程，然后运行SqlCommand。对于每个对象都要重复的写这些代码。
 
 　　除此之外，还有更好的办法吗？有，引入一个O/R Mapping。实质上，一个O/R Mapping会为你生成DAL。与其自己写DAL代码，不如用O/R Mapping。你用O/R Mapping保存，删除，读取对象，O/R Mapping负责生成SQL，你只需要关心对象就好。
 
       对象关系映射成功运用在不同的面向对象持久层产品中，如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。
 
       一般的ORM包括以下四部分： 
       一个对持久类对象进行CRUD操作的API； 
       一个语言或API用来规定与类和类属性相关的查询； 
       一个规定mapping metadata的工具； 
       一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。
 
 一、目前流行的 ORM 产品
 
       目前众多厂商和开源社区都提供了持久层框架的实现，常见的有：
 
       Apache OJB （http://db.apache.org/ojb/） 
       Cayenne （http://objectstyle.org/cayenne/） 
       Jaxor （http://jaxor.sourceforge.net） 
       Hibernate （http://www.hibernate.org） 
       iBatis （http://www.ibatis.com） 
       jRelationalFramework （http://ijf.sourceforge.net） 
       mirage （http://itor.cq2.org/en/oss/mirage/toon） 
       SMYLE （http://www.drjava.de/smyle） 
       TopLink （http://otn.oracle.com/products/ias/toplink/index.html）
 
       其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。
 
       其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。
 
 二、对象－关系映射模式
 
       从《公共仓库元模型：开发指南》一书第8章CWM元仓库中摘录出来的内容，实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射，是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。
 
       基本情况：公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准，采用UML表示的对象层次结构，在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流)，所以该书的作者倾向于使用成熟的关系型数据库来保存－这也是存储本体时所遇到的问题。
 
       采用方法：将UML模型中的各种元素通过转换，保存为数据库模式。由于CWM是一种元模型，因此模型的实例也是一种模型，将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。
 
       1、数据类型映射模式
 
       1.1简单数据类型模式：建立UML和关系型数据库中简单数据类型的映射表以指导映射。
       1.2枚举数据类型模式：每种枚举类型对应一个表，只有一个列(_EnumLiteral)表示枚举值。
       1.3基于类的数据类型模式：使用外键约束，将基础列与基于类的类型实例相关联。
 
       2、类映射模型
 
       每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射，而引用属性将在关联映射模式中提到。
 
       2.1单值属性模式：是cardinality的上界为1的属性，映射到类所对应的表的列上。若其下界也为1（必须有的属性），列属性为NOT NULL。
       2.2多值属性模式：每个多值属性映射成一个独立的表，使用外键连接到类所对应的表上。
       2.3继承模式：每加入一个类的实例时，根据其继承关系自顶向下生成每个类的对象，这些对象具有相同的ID（根对象对应记录的主键）。删除对象实例时，自底向上删除数据。遇到从中间删的情况怎么办？多重继承怎么处理？（金龙飞）
 
       3、关联映射模式
 
       3.1一对一关联模式：在关联两端各加一列。
       3.2一对多关联模式：和3.1一样。如果多这端是有序的，还需加入一列表示序号。
       3.3多对多关联模式：将关联单独作一个表。
       3.4组合关联模式：注意级联式删除。
       3.5反演关联模式：关联两端指向相关的类型，和普通关联一样。
       3.6成对关联模式：关联记录两个类间的关系，用交集类表示关联，表示成一个单独的表，每个关联对应一个表，用外键表示它们间的关系。
       3.7关联上的OCL需要分析成对应的存储过程代码。
       3.8保证关联的cardinality也需要分析成对应的存储过程代码。
 
       4、引用映射模式
 
 
       在UML中不存在的MOF特征，指属性是声明为引用类型的实例。用存储过程实现。

       公用对象请求代理（调度）程序体系结构（Common Object Request Broker Architecture），缩写为 CORBA，是对象管理组织（Object Management Group）对应当今快速增长的软硬件的协同工作能力的要求而提出的方案。简而言之，CORBA 允许应用程序和其他的应用程序通讯，而不论他们在什么地方或者由谁来设计。CORBA 1.1 由对象管理组织在 1991 年发布。他定义了接口定义语言（IDL）和应用编程接口（API），从而通过实现对象请求代理（ORB）来激活客户/服务器的交互。CORBA 2.0 于 1994 年的 12 月发布。他定义了如何跨越不同的 ORB 提供者而进行通讯。
 
 
        ORB 是一个中间件，他在对象间建立客户-服务器的关系。通过 ORB，一个客户可以很简单地使用服务器对象的方法而不论服务器是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求，传递参数和方法，最后返回结果。客户不用知道对象在哪里，是什么语言实现的，他的操作系统以及其他和对象接口无关的东西。
 
 
        在传统的客户/服务器程序中，开发者使用他们自己设计的或者公认的标准定义设备之间的协议。协议的定义依赖于实现的语言，网络的传输和其他许许多多因素。ORB 将这个过程简单化。使用 ORB，协议定义是通过应用接口，而该接口是接口定义语言（IDL）的一个实现，他和使用的编程语言无关的。并且 ORB 提供了很大的灵活性。他让程序员选择最适当的操作系统，运行环境和设计语言来建设系统中每个组件。更重要的是，他允许集成已经存在的组件。
 
 
         CORBA 是在面向对象标准化和互操作性道路上的一个信号。通过 CORBA，用户不必要知道软硬件的平台和他们处在企业网的什么地方就可以操作。
 
 
        ORB 结构
 
        下面我来用些图形说明一下：
 
 
 
 
 

  通过 ORB 发送请求
 
 
 

  
 
 
 
 
 
        上面的图形说明的是客户端发送一个请求到对象的实现。客户端是希望对某对象执行操作的实体。对象的实现是一片代码和数据来实际实现对象。ORB 负责下面的必要的机制：对该请求找到对象的实现，让对象的实现准备好接受请求，和请求交换数据。客户端的接口完全独立于对象的位置，其实现的语言和其他不影响对象接口的东西。
 
 
 
 
 

  ORB 接口的结构
 
 
 

  
 
 
 
 
 
        上面的图形显示的是一个独立的对象请求代理（ORB）的结构。ORB 的接口是灰色的矩形。箭头说明 ORB 的调用关系。
 
 
        为了提出一个请求，客户端可以使用动态调用接口（Dynamic Invocation Interface）（和目标对象的接口独立）或者一个 OMG 的 IDL 占位程序（具体的占位程序依赖于目标对象的接口）。客户端也可以直接和 ORB 在某些地方交互。
 
 
        对象的实现通过 OMG 的 IDL 产生的骨架或者是一个动态骨架的调用来接受请求。对象的实现可能在处理请求或其他的时候调用 ORB。
 
 
        对象接口定义的定义可以有下面两种方式。接口可以通过接口定义语言静态的定义，这叫做 OMG 的 IDL。该语言按照可以进行的操作和该操作的参数定义对象类型。或者（也可以作为补充），接口可以加入到 Interface Repository service。该服务描述了该接口作为一个对象的组件，并允许运行时访问这些组件。在任何 ORB 实现中，IDL 和 Interface Repository 有相同的表达能力。
 
 
 客户端使用占位程序或者动态调用接口
 
 
 

  
 
 
 
 
 
         客户端通过访问对象的对象引用和了解对象的类型及要求执行的操作来发布一个请求。客户调用占位程序例程来请求或者动态构造请求。
 
 
        无论动态还是占位程序的接口都可以相同实现。接收方不可能知道请求是如何发布的。
 
 
 对象的实现接受请求
 
 
 

  
 
 
 
 
 
           ORB 向对象实现定位适当的代码，传递参数，传输控制。这一切都通过 IDL 骨架或者动态骨架。骨架对于不同的接口和对象适配器是不同的。在执行该请求的时候，对象的实现可能由 ORB 通过对象适配器来获得一定的服务。当请求完成，控制和输出值返回给客户。
 
 
         对象的实现可能会选择使用的对象适配器。该决定基于对象的实现要求的服务。
 
 
 
 
 

  接口和 Implementation Repositories
 
 
 

  
 
 
 
 
 
         上图说明的是接口和实现信息如何让客户和对象实现访问的。接口用 OMG 的 IDL 和/或 Interface Repository 定义。该定义用于产生客户占位程序和对象的实现的骨架。
 
 
        对象的实现的信息在安装时就提供好了，储存在 Implementation Repository 中以便请求发布的时候使用。
 
 
 
 
 
 2009-09-07                   
 
 
 注：源自原百度博客“至美心”