SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 4999|回复: 2

[推荐] 开发企业架构的实用指南

[复制链接]
发表于 2012-4-23 13:57:01 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2012-4-23 14:12 编辑
2 }( M4 I/ ~* z# v: o$ O' l' W  R
6 q# p" q1 F7 |4 Z9 l: A. N( U9 m企业架构是业务及其支持数据、应用程序和 IT 基础架构的逻辑组织,为未来的业务成功明确定义了目的和目标。典型的架构由展示业务的各个方面如何关联的一些图或模型组成。例如,组织结构图是表示业务单元如何相互关联的模型。
5 L6 f$ d. ^) D6 F0 P
/ ~! t& F7 ], l  P$ X) L& S3 \企业应该有一个代表其当前状态的 “原样” 架构,并且有一个规划架构,以显示在未来一年至五年的业务方向。
6 x$ w' x7 S- [; I) X企业架构应该协调以下关键领域。请注意每个领域中的示例:0 `% [3 E- Z% g, b3 d5 M
  • 业务:流程、战略、组织结构图和职能
  • 信息:概念性、逻辑和物理数据模型,显示需要哪些信息,以及如何与其他信息(比如客户和订单)关联
  • 应用程序:应用程序组合、接口和服务
  • 基础架构:网络概念图、技术参考模型8 @( U! z! I7 q; d: z8 H
为了实现协调一致,需要从每一个关键领域的视角对其进行建模,然后从各个角度链接模型。例如,从业务的角度对业务流程建模。不包括应用程序等内容。然后,将业务流程链接到支持它们的应用程序,这样就可以帮助您实现协调一致。我们这样做是为了确保每一个决策都是根据业务需求制定的,因此,应用程序并不会规定业务流程的设计方式。" _, l9 l( B2 g3 t+ k3 S/ W
本文假设您有一个建模工具,可以用该工具创建您的架构。本文中特定于实现的信息以 Rational System Architect 为基础的。) M, U% i; v8 _( E( Y4 E, P
“我们打算做架构......我们要做架构!”, |3 v: Q0 V: ]5 r3 V3 S1 ]$ J9 f, n/ _
! {8 a% Q4 M, S; @; S
图 1. 如果您没有一个目标,您的项目将会失败
8 c- A7 M* H$ l% o( r" w  d+ y 4 {( y* w8 L& t8 t* u9 S
确保您的架构失败的最简单方法是毫无目的地制定架构。我已和数百家客户合作过架构项目。当项目没有成功时,我问他们为什么要创建企业架构。他们回答:“因为我们想要一个架构!”4 Z8 C2 }0 A5 U8 I  W

  J) v3 p+ B6 O$ a, ?3 Y9 E

3 W+ x8 z( |. d% Y第 1 步. 确定架构的目标
( O& `6 |. b2 Y# D& ]5 e您可以通过询问以下问题来定义架构的目标:
$ `9 b$ d& x8 o3 o
    8 z7 Q: L5 M" W: M3 V4 R) m1 Z$ ]

    8 X4 [! A4 v8 l+ l, L0 M7 G) }6 x. P
    # z0 ~; ~7 Q& D+ J4 ]% {: C2 E/ d3 \/ ~# s$ {' U$ \
    • 哪些信息对于架构是重要的?
    • 支持分析和决策需要多少细节?
    • 谁将生成或使用架构?
    • 架构的预期投资回报率是多少?
    • 维护的考虑因素是什么?
      & [) J$ b2 k  X! s  y+ o
如果您无法回答这些问题,您的架构项目很可能会失败。如果没有目标,您可能会浪费几个月来绘制没有人关心的业务流程图。或者您可能绘制了一些复杂的应用程序接口图表,但无法提交给高级管理人员,因为这让他们感到头疼。
- q4 T8 Y  Z# O4 ]- j; \以一家连锁酒店为例,将酒店经理确定为 EA 的受众。
7 k1 G( q% O; L2 X: k0 F( f+ ~4 k7 s8 y- x+ ^6 e, z+ |

0 O! N, k5 G2 Z通过了解架构的目的,您可以确定必需的模型和所需要的数据的范围,从而确保人们使用您的架构进行分析和制定业务决策。( }8 C7 `. A" U4 W0 p
首次涉足架构时不要走极端。即使您拥有一个非常大的经验丰富的团队,您也无法捕获有关组织的所有信息。
' U; ?3 m+ y4 m: ~0 y同样重要的是,请记住,全面的架构可能会混淆重要的事项。例如,如果只有 50 个业务流程对您的业务是至关重要的,捕获 5000 个业务流程就是没有意义的。识别您的关键业务问题,并使用它们成为您的第一个架构项目的重点。 - z' Z; P4 @0 H" i+ S6 T
' |; a! \2 W6 u. ]( h
图 2. 架构为回答问题提供了一条路线
: f4 [8 b( |+ n
$ R+ G6 N8 e$ b1 r3 O( M
& W8 j( v, x/ ?: ^; j2 Q7 I
7 T( P) l  S- @  z2 @
第 2 步. 确定业务问题
) R% X9 y$ I) n' q, \" p# p) z0 g我与客户做的第一件事,是讨论对其业务至关重要的一些问题;然后我帮助他们确定哪些是他们难以解决的问题。许多客户都需要回答以下问题:8 }* T: a4 h5 l# f% w, z
酒店做架构的目的是改善入住登记和退房的体验,使他们能更具竞争力。
& Y* w6 r5 I; m* ?# f
* Q) }8 D$ H; A" z# |4 X4 z- e) N7 G5 S
  • 不使用某个应用程序的影响是什么?
  • 某个位置迁移的影响是什么?
  • 需要使用哪些应用程序来支持业务流程?
  • 更换服务器的影响是什么?
  • 需要制定什么流程来支持新的战略?
  • 在我们的应用程序组合中,存在哪些不足或重复现象?
    . u7 X0 x% g9 i7 |; K; j! g! v. G
您的问题将促进架构内容的形成。如果大多数问题都涉及您的应用程序组合,那么您需要将重点放在定义应用程序领域。如果需要了解流程如何支持一个新的战略,那么应该将重点放在业务领域。然后,就可以开始通过新的业务问题拓展架构的范围。
0 [# F  s) E! m6 `

+ V% Y1 a8 q# i  C1 _第 3 步. 确定假设和业务规则
9 a1 v, P, @1 `  S0 M: J, l9 q
( O/ T) {  K6 V$ Q1 W, H' b现在,您已经确定了受众、目的和问题,然后应该确定用来限制或解释关注领域的业务规则。7 I+ l  m5 j' R; J
每个业务都有规则。例如,如果您打算捕获关键业务流程的信息,则必须捕获该流程的所有法规或企业标准。举个法规方面的例子,健康保险流通和责任法案(Health Insurance Portability and Accountability Act, HIPAA),该法案保护工作变更的人的健康保险的承保范围。然后将创建一个企业规定,显示该公司是否满足 HIPAA 的要求。
% x7 l9 Z' L) t您应该捕获与架构有关的假设,如 “新应用程序的信息将在周五上传” 或 “每一个业务单元都要负责记录业务流程”。9 _3 D2 X! \4 x  q* `


6 L% D+ M5 d$ H; a9 {2 e! ~* c3 J3 |3 @% A8 E, j2 ]  s
第 4 步. 确定框架( w0 S) M. y, t) C8 S# S

% y! n% w. ^. O- V+ n4 L以下行业标准框架可以帮助您创建一个企业架构:
) T$ G% S3 q, k: @
  • ToGAF
  • Zachman
  • EA3
    + ?7 M; _) q" v  ^& o4 D/ y  Q
  • DoDAF* P* \$ I* ?. ?) {
使用标准框架,可以为您的架构提供一个 “骨架”,然后,您可以利用它建立您的模型。
4 e3 p. j" t5 t: ?+ l) z框架还提供了一些指导,指导您了解需要根据将要使用架构的利益相关者来捕获哪些信息。它提供有关组织信息的指导,但没有为您的架构建议具体的实现。
8 W8 m5 ]6 B! u5 D: WInternet 有大量关于这些框架的信息。您要选择什么框架主要取决于您的架构的目标、团队的经验,以及您是想遵循 ToGAF 这样的已定义的流程,还是仅像 Zachman 那样,帮助确定出于什么目的使用哪个模型。* @: z- R4 h. W4 B. U8 H, B
您还可以组合多个框架。TOGAF 和 Zachman 经常一起使用。
7 T2 K7 f) H( f& {8 w; Q, O
2 b) U4 Q' l) v# {2 C% J5 Z图 3. 您的选择应以您的目标为基础,不要作出随机选择* `: ^3 r. F' O7 H; K& h
. k9 O/ D/ w" j+ x$ X
如何将框架融入架构?
3 |+ {0 K+ }1 q2 Y4 u0 h% @框架提供关于建模对象的指导。然后使用一些方法来创建模型。
2 C& [0 l8 t; O, k" M方法是一个规则集,说明了如何对某个对象建模。例如,业务流程建模标记(Business Process Modeling Notation, BPMN)方法提供了用于业务流程建模的精确的规则和标记。& a. d, h; i. @, L. T. R

" }+ K# R8 t* P( i图 4. 框架有助于确定方法的选择, L8 F. p6 o+ {0 E& ~3 C0 v: i

0 |+ {" [9 ]) x' U框架有助于组织架构的关键领域,并确定您需要建模的视图,比如,解决业务问题所需的角度和数据。
/ W' P% \0 Y& a0 n7 o% w连锁酒店决定使用 Zachman 框架。7 i0 M; e" `9 v* s
9 k! Z" @$ A; w0 }
. D$ W& ^6 D) H4 |  \' X
尽可能使用行业标准的方法,而不是 “内部开发” 的方法。行业标准的方法包括规则集和标准的建模方式。多数内部开发的方法无法以有用的方式捕获信息,因为​​没有明确定义的规则集,这使人们以多种方式对相同的信息进行建模。这也会影响分析,因为信息没有按照标准进行捕获。! X+ A# c% m) ^! f& a5 Q
根据需要的信息类型,可以生成多种模型来支持框架。
) M! d: l0 ]1 e; r% X5 {4 [7 L
. D8 ]& t7 j# C. @6 G图 5. 框架及所支持的方法
1 U0 V( t" t& P; l1 K9 q9 C7 q+ Y* x
5 E! A/ s. {. y7 N3 n

8 p4 G. v6 n; ?! j$ U7 R
3 l/ e3 `, d2 r第 5 步. 创建一个元模型  y! N: B: j+ J9 i7 F! _
元模型是架构的一个抽象视图。它显示您正在尝试捕获的数据以及数据之间的关系。这是您实现协调一致的地方,它以您的业务问题的解答为基础。4 }$ T, {! F6 R1 b2 ?+ t9 A' \
例如,如果您需要了解支持特定业务流程的应用程序,在您的元模型中必须存在这两者之间的关系。否则,数据之间不存在任何联系,您无法解决您的业务问题,架构也无法发挥其作用。
9 |! ]+ b# |' P& O1 k  J" g请注意,在元模型中,您可能并不希望所有数据之间都存在直接关系,您应该只将存在逻辑关系的东西放在一起。例如,将组织部门与技术相关联没有任何意义,但将技术与应用程序相关联就有意义了。Rational System Architect 等良好的建模工具支持通过遍历元模型来创建复杂的报告。所以,在这个元模型示例中,您可以报告支持某项业务功能的硬件,即使两者在元模型中并没有直接关系。在元模型中,您可能从业务功能遍历到该功能所拥有的某个业务流程,再遍历到业务流程的位置,然后遍历到该流程所需要的支持应用程序,最后,遍历到支持该应用程序的技术。
( B  Q; C8 C; Q3 y9 t! W1 g
! X3 D6 }. u* n' B' D+ q图 6. 关系(元模型)示例
" |" m& ~8 m. E- z! N9 a 6 O% @6 w& f3 b, B
您的元模型应该包括以下特性:
/ r+ z4 [& _: y4 R2 F0 H; o- _- q! x

    3 l2 u' d5 O* _
    / d+ R/ O; S% @0 d1 Y- M. A& @* d& z' Q1 {: R) g) E- C2 S$ j  K2 l

    : i; Y! O0 b* n7 C
    • 架构元素之间的关系。例如,业务流程和应用程序的关系。
    • 元素的定义。例如,术语 “应用程序” 的意义和您将捕获的属性。
    • 业务问题的可追溯性。例如,如果您的问题是 “什么应用程序支持什么业务流程?” 那么您应该知道,元模型中需要一个业务流程和一个应用程序,它们之间存在直接或间接的关系。
      # {, P! N/ `. w! s7 v

1 Y/ v' ?1 l( k8 w$ _, n

1 \) a+ d2 t7 B5 z- x第 6 步. 确定架构中所需的模型- c  R0 {1 q% p8 }, M$ d, @" K, ~
+ \! U2 Q* u% X. `4 n
现在您已经确定了您的业务问题、框架以及解决问题所需的元模型,然后还需要了解要绘制什么样的模型。5 s1 X& a" W  X/ I
将业务流程作为一个例子,有许多行业标准支持业务流程的建模,如 BPMN 和流程图。请根据以下条件选择您的建模方法:
/ k5 x" V3 g5 N0 b
  • 信息的受众。管理者理解如 BPMN 等简单的图表;软件开发人员通常喜欢 UML 序列图或用例。
  • 元模型的元素。如果在您的元模型中,您需要了解数据以及与它相关的业务流程,请考虑使用 BPMN 对其建模。相反,如果您只是担心流程步骤的顺序,请考虑创建一个流程图。8 l  ]- K' Z1 g% s  G$ L
知道受众和您想建模的内容之后,您就可以确定您需要创建的图表。在上面的例子中,因为您需要有关业务流程和系统接口的信息,您可以选择以下模型:, _, U1 a, s, D; ~6 j. a2 F
    2 ~7 F9 U9 d/ N7 t4 }
    5 ~7 E! H8 m; D6 ^$ j* g

    0 m! a* S& [( J3 ^7 ?  X. ~% g6 r0 R* \
    • BPMN(捕获业务流程)
    • 系统架构(捕获应用程序)' [1 d' u7 @' k, C2 [, e
以酒店为例,他们需要回答的业务问题是 “什么应用程序支持什么业务流程?”
' S% k! J* h% u  l
+ o- Z# l0 n7 ^: I( o& ^+ n7 f, A; X% c
重要的是,请记住,您不能用单一图表来创建 EA 中的一切。此外,架构视图的分离是一种最佳实践,如应用程序视图与业务视图分离。如果您尝试在同一个图表中完成两个视图的建模,这样做往往会造成混乱,并且无法以有意义的方式捕获信息。
$ V- {: R3 s, ?( F, |0 V
7 w) c6 ?$ k2 C  o) ?# f2 u4 V  y, m8 k图 7. 使用模型来解决业务问题,所以架构是有用的…# a, @; V6 ]& s4 l, D# a% X

0 N, r2 M- |2 w2 Q# K) c, O% C, U# |$ Y- N- u: c, c$ I7 U5 b
0 X9 }# x4 L- D0 g& F2 x
图 8. …不要为了建模而建模5 l: A9 A4 I7 r& C2 M) N( ^+ L
3 O* r/ N  A" R  x. B7 G( W
正如 Will Gadd 所说,“只是出来走走,做点不那么重要的事情,这样做我就已经觉得很高兴了。”" G) F6 f4 }9 T3 R5 Z3 ^8 a
使用合适的工具
9 `7 ]& M/ T# T/ u单一的建模工具或方法并不能提供完整的解决方案。除了开发模式的工具之外,您也应该有发布、需求管理和仪表板显示等工具。仪表板在饼图和条形图等容易理解的图表中展示您的企业架构信息。3 n% Z5 o8 @6 k
如果您的架构工具是可定制的,则意味着将使用一些改变工具原有用途的问题定制。大量的定制通常标志着使用了错误的工具或方法。还请记住,定制会带来架构上的管理开销。* o! t2 ?' i# V  b2 d0 c/ I/ {- T& D
有些客户通过定制架构工具来创建自己的模型。这并不是最佳实践的方法,特别是如果 “模型” 是占满了整面墙的单一图表,其中包含了关于您的架构的所有信息,这肯定不是一个最佳实践。我们不应该创建墙纸,而是建议创建报告。并不是一切都需要在一张图上显示。
0 ?" g+ w  B+ B0 }& l' G在创建架构时,人和工具同样重要。一个人不可能在架构的每个方面都是专家,因此需要发展一个成熟的团队来支持架构。关于架构团队的理想特性的列表,请参阅本系列的第一篇文章,从您的企业架构顾问身上获取最大价值
: Z$ {1 S( c# ]' Q

* J/ H& {, F+ F( s6 e: z
8 Z+ |1 m1 J5 T8 d3 ?. P) p第 7 步. 整合架构
! |- `$ |5 |. o. \6 f5 y) w7 D' G. E; D6 c0 M+ {
将您根据之前所确定的关系捕获的数据链接在一起。无论销售人员跟您说的话有多漂亮,不要相信,一个工具是无法奇迹般地做到这一点。此外,如果没有一个资料库,关系的链接真的很难做到。如果有人建议说该项目可以使用电子表格做到这一点,那么寻找另一个项目可能会是一个明智的决定。( E% `% t" X' O: |
如果您现有的项目或业务线已经有架构,并且您想创建一个企业架构,那么最简单的方法是自下而上填充您的 EA。采用现有架构,并将共同的元素放进一个资料库中。具体而言,可以尝试标准化整个组织中使用的模型和术语,因为可能每个人都对同一个组织使用同一个名称,比如,不是同时使用 “财务部”、会计或财会等别名,而是将它们标准化为 “财务”。& g: k5 z$ F2 h
如果这是您的第一个企业架构,那么请在整个组织中使用一个公共的蓝图,使用与企业架构相同的框架、术语和模型为业务线创建一个架构。这样,您就可以报告整个业务。
6 `; H$ n/ g2 d' ]9 d+ E3 |: O分析架构
0 K6 m! W6 }4 `8 P" g, l4 `' d$ K% s3 N  `  B+ f  t9 |
图 9. 为分析节约能源!
( z, \  A; v4 R4 {6 e
* p2 B$ R/ F7 B2 y0 I7 v7 T: |如果您不愿意花时间来分析架构,可能就不会去分析它。如果不分析它,那么为什么要构建它呢?在时间表中,这关键的一步常常被忽视。至少应该将 50% 的模型开发时间分配给分析,这包括审查模型以验证和确认它。& v7 M+ B! u7 f  o0 m; H$ \5 r' a3 @) }
然后执行定量和定性分析。此时数学很重要,在显示投资回报率时尤为如此。如果您使用行业标准方法(如 BPMN),则可以使用定量分析来显示缩短流程、节省时间、节省成本和消除冗余中的瓶颈。 BPMN 是 “结构化” 的,因为它有一个您不能违反的规则集。这些规则确保您可以执行分析,比如分析模拟业务流程的变化,看看该变化是否能够节省时间或金钱,或者是否会造成瓶颈等负面影响。
/ |/ V4 u6 o: _5 N$ B6 ]通过查看模型,可以找出潜在的问题所在,然后完成定性分析。例如,如果您有一个业务流程反馈到流程的早期阶段,那么这通常标志着该流程必须返工。消除流程中的反馈回路是改进流程的一种方式。% r; \( P( n$ I7 {' _  H
完成分析后,就可以与他人共享成果。如果人们学会了如何使用架构,就会看到它的价值。报告在这里是关键,所以在选择企业架构工具时,请确保它提供了强大的报告功能。
, ^4 _$ p& p* y( q1 ~不要忘记,您需要一个游戏计划
$ E1 t) a# e( M$ m
/ m+ |; N, ]0 k图 10. 制定您的 EA 游戏计划" P: W+ s- R& I8 N- [
9 U8 ?- ?- v& q) H5 z/ Q
人们常常忘记,需要在解决了许多管理问题之后,才能启动和支持 EA 项目。需要解决的一些管理问题包括:0 e0 L! }! Y0 R9 b6 S9 z
  • 如何部署企业架构?
  • 在哪里部署它(Web 站点,等等)?
  • 谁是团队成员?
    / G5 i, n- r$ C8 P6 I2 Z5 J/ H
    • 审查委员会
    • 项目管理
    • 行政管理2 i: z; h6 C$ i9 \) Z
  • 谁将使用信息?
  • 谁将可以访问信息?
  • 将要遵循什么标准?  D  S5 V- k1 W; y0 q  t
    • 命名约定
    • 颜色编码
      1 C4 v$ q2 E. B
团队里有一个 "EA"" t8 }1 L! ^8 G$ F, w4 E# ]
) l: i: q3 B1 i! k" p0 s) m
图 11. 良好的 EA 团队确保成功+ ^& ~& z; ~& t

0 H0 F8 ?' Y' e3 [! n您不能凭空创建架构。您必须做好准备,与 EA 团队以外的人合作,否则用户无法采纳和使用您的架构。此外,您还要确保利益相关者(例如,付钱让您构建架构的人,或者帮助您构建架构的人)参与了您的决策。
$ R9 \8 P% L2 i. q3 U治理是制定决策所必不可少的。治理有助于定义您将在架构中使用的规则和战略。以组织中的业务线命名的治理为例,人们可能不希望出现某人将这个部门称为 “会计” 而其他另一个人将它称为 “财务” 的情况。治理也决定了哪些模型已准备好发布为 “批准”。成功的 EA 所需要的典型委员会包括:3 S. `2 }4 l' M1 v, n& P
    5 h4 B# w4 y. f" u) W& c) y0 A$ f

      v; L3 h, }" f/ w  n+ t0 J* K' U3 ], O# R, ~" F! K
    # z1 C/ Q( S, ]+ b# O
    • 架构审查委员会
    • 配置和控制委员会
    • 管理指南(例如,谁可以创建模型,审批流程的什么,变更请求的流程是什么)
      , l! [7 }2 P$ V  L) M/ C
越多人参与支持架构,使用该架构的机会就会越多。$ `! Y* ^' S) @4 c, |$ q* k
最后几点建议4 q- {+ ~6 u: t" f% T: D9 p3 c
如果建立架构看起来很难,那是因为它的确很难。但这也表示您在以下其中一个方面犯了错误:
" `1 M" @# A7 H' C
    , o+ ?/ Z" {' k+ S# o
    % b# [1 @" x( f8 {$ H  k

    4 b: {5 t  M  X9 O; [6 N# p2 U0 C
    • 模型。例如,使用一个 BPMN 模型来捕获应用程序界面。
    • 利益相关者。例如,不熟悉业务流程的人提供输入或反馈,而不是由真正做流程的人来提供这些信息。
      2 N% u! v* g2 J" U5 |
学会从架构中将政治原因分离出来
& w" W  u- y4 E9 e  {, l5 s6 x
    8 ?. Y" Z* R' }: p" }: I; c# u
    $ v7 C/ E- h2 }8 z0 U7 w
    ! M% g9 G1 u+ q+ k& H. O* y5 F" x

    , ^( [0 L2 q+ [
    • “不要记录那条信息,否则人们会知道我们做错了!” – 这是对企业架构的一个常见反应。但是记录理想化的视图是没有意义的,因为您无法规划未来纠正问题的方式。
    • “我的组织正在使用不同的方法捕获我们的架构。” – 在我合作过的每一个组织中,总会有一个业务线不希望以标准的方式开发他们的架构。没有人是特殊的。没有人有不以标准方式做事的正当理由。处理这种情况的最佳做法是培训那些希望与众不同的笨蛋。如果他们对期望的目标感到满意并了解他们的期望,那么他们会愿意遵循标准。如果这个方法无效,那么您惟一的选择就是打断他们的腿。
      6 _5 W0 `: {0 T4 x+ ?
使用架构打破独裁9 S" I" a$ @5 y) W; t2 w& X
    : ~. l; ?% ^- p  ?9 g8 c1 i' S' A( _
    ; _- a* M! O& H0 i% L. n5 m

    ! T9 s/ L! W* q. U3 h- p6 }
    7 ^% j+ O& E4 j7 J+ j
    • “我们没办法跟那些家伙沟通,您知道,他们是做软件的。” – 在大多数公司都有些人认为与软件开发人员谈话是一种挑战。在您了解他们后,就会发现他们其实都是一些好人。并且,如果他们发现可以用简单的方式与您沟通,可以使用图片,而不是无意义的 500 页需求文档,那么他们对您的态度也会随之改变。
    • “我倒是愿意把数据给您,但我需要先与我的管理层确认一下。我下次再回复您好吗?” – 有些人认为隐瞒信息可以保住工作。如果 Barney 是惟一了解您的应用程序如何连接在一起的人,那么您就不能解雇他。其他业务线可能不希望共享信息,因为他们怕您用这些信息来解雇员工。通过解释将要采用哪些信息,以及如何让提供信息的人从中受益,可以处理这些情况。如果您带着不可告人的目的(如,解雇员工)来使用信息,那么您会看到愿意向您提供信息的人数会急剧下降。2 c* ^! N# K" R3 ?& K0 w7 V! ]/ g

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2012-4-23 13:59:11 | 显示全部楼层
回复 支持 反对

使用道具 举报

发表于 2012-5-23 08:38:48 | 显示全部楼层
在天愿作比翼鸟,在地愿作同圈猪!
  W$ x8 o7 r% w8 w) N( m% q/ V" `; G% k9 ]8 E- f3 N
嘎嘎$ h6 X3 t* H, v0 Z  R/ g! v6 k
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-12-12 12:21 , Processed in 0.071818 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表