1：IT部组织体系建设
决定来写这个系列的文章，是因为从之前招聘或者从技术培养IT部门的领导，很难。很少有人会有我这样的职业经历，从技术人到管理者似乎很难跨越，希望这系列的文章可以给大家一些启发。
在科层制的传统组织架构中，一般企业对部门的划分可以划分为经营性部门、职能（服务）性部门这两种类型的部门。对制造企业来说，也会分为经营性部门，研发设计部门，供应链部门，职能（服务）部门。但不管怎么划分，IT部基本上是归为职能（服务）部门。
企业战略被分解和落实到部门，才会形成部门的职责。意思是部门存在的价值是被战略落地所需要，为战略服务。就职能部门而言，大家很容易想到的是财务就是管好钱，人力资源就是管好组织和人。这就是传统的每个企业都会有的职能部门。那么问题来了，IT部门在企业中的职能究竟应该是什么？究竟应该干什么？这似乎是不太明确的。而且在我的理解中，IT部门的职能是随着企业的不同阶段，企业的规模，企业的发展战略而不断变化的，呈现出的内容或许会截然不同。
1.1-IT部的职能
当一个企业软硬件都很少，人数很少，规模很小的时候是不需要有IT部门的。我把软硬件放在第一位，因为IT的具体工作是围绕网络、服务器、终端硬件、系统、数据来展开的。所以，当这些很少的时候这个职能就可以忽略不计。
当一个企业到了一定的规模，有了网络、有了服务器、有了系统、有了数据，那么就需要有人来管。从企业战略分解的角度来看，对传统的制造、零售等企业而言（除非创新型公司IT承担经营性的职责），IT是战略落地的底盘，是为所有的部门提供更高效的完成战略目标的工具和抓手，是衡量整个业务及管理过程是否有效的抓手。
所以，我对传统企业IT部的定位是：IT部是一个IT规划和运营支撑的部门。
1.2-IT规划：
IT的项目建设，数据积累是一个长期的过程，对企业来说投入巨大。所以IT的项目建设是需要跟随企业战略的落地去统一规划和分步实施的。这件事情并不容易做。因为一方面需要对战略和组织有充分的理解，要考虑战略和组织的发展，变化，需要有一定的灵活性又要保证连续性，对业务的适应性，还要适当考虑IT技术本身发展。
1.3-运营支撑：
所谓的运营支撑，基本上是要做好以下几件事情
A，安全稳定运营：
无论是网络、系统、数据、设备，这些日益成为企业运营的必备工具，智能设备越来越多的成为生产工具，那么确保其安全稳定成为最重要的职能之一。每个企业对系统的故障和宕机的容忍程度是不一样的，所以取决于企业对这些内容的依赖程度，来评估这个职能的重要性。
B，提升及规范运营效率：
网络、系统、数据、设备存在的价值是为了提升企业整体的运营效率。把“规范”这个词也加入进来，是因为在系统中走的业务流程，是固化的，起到了把企业制度及规范落地的作用。有了系统的规范，企业的日常运营才不会是人治而是“法”制。日常企业运营流程的规范化，本身就可以提升企业的运营效率，可以把事务性的工作交给系统去处理腾出更多的精力和脑力来关注异常。
C，IT软环境的建设：
任何的投入，企业都希望产出实效。如果我们把IT的项目投入，软硬件的投入作为一种投资的话，要产出实效并不仅仅在系统或者软件本身。
我打个比方，如果你买了一部手机，但你不会用，那么这个手机有价值吗？所以手机的价值并不是手机本身，针对智能手机，除了通讯基本功能外，通过各种APP，还给你带来了资讯，娱乐等一系列的价值。
那么，IT的软环境的建设包括了两个层级的含义：
让用户会用，了解基本功能，了解各种软件怎么用的。
更深层次的要告知用户，怎么要把一个业务问题，转化为一个数据可分析的问题来通过系统和报表、数据来跟踪和测量问题是否得到解决。
所以，IT软环境建设中一项具体的工作就是培训。
IT的职责和核心，无论网络、系统、数据、设备都All In One就是要产出实效。其实，效率也是实效的一个体现。
1.4-IT部门
在上面我们已经把IT部门需要承担的职能讲清楚了，那么IT部门是需要独立存在吗？或者说IT部门是要作为一级部门还是二级部门？
要回答这个问题，还是要回到战略落地和组织体系的构建问题上。组织体系的设计，也是要围绕更高效的完成企业发展和战略目标落地去考虑的。这还是一个效率问题。这里讲的效率是指组织内沟通和协调的效率。
当然就组织建设而言，因为有人的问题，所以不仅仅是理论上的组织构架，还要考虑的诸多因素。但组织要发展，构架就是应该随需而动。
部门职责落地数字化思考
部门职责落地，数字化要考虑两个方面：
一个是从目标设定到目标完达的量化。
一个是过程管控中的流程化规范化。
2：IT部体系建设
有了部门职责，有了岗位划分的原则，那么具体在IT部内部组织架构应该如何组织？具体岗位应该如何设置？人员应该如何安排呢？今天我们继续探讨。
在上一篇中，已经提到，岗位设置的原则应该是因事设岗，同时也讲到了要充分考虑成本效率及领导者的价值问题。今天我们具体来谈谈究竟应该如何来组织IT部门的岗位和人。
2-1:IT部的岗位设置
刚刚工作的时候，我记得有这么一句话来描述IT部：只要跟电脑相关的，都跟IT部有关。意思就是说，跟电脑相关的问题，就找IT部解决。所以就引出了这样的一些工作（事情）和岗位：
基础（桌面）运维：电脑坏了，无论是软硬件，都归你管。
网络管理：跟机房，网络，服务器相关，都归你管。
系统运维：有了大型的应用系统，比如ERP，为了确保系统运行正常，系统运维自然就产生了。
项目管理：公司要有信息化项目的建设，项目管理应运而生。
软件开发：有一些软件开始由自己开发了，那么软件开发岗位自然就需要了。
数据分析：如果系统沉淀了数据，企业对数据开发利用的要求越来越高，数据建模和分析的事情就来了。
你会发现，要做的事情种类越来越多，岗位自然也越来越多；企业对数字化应用水平越高、对IT的依赖度越高，IT要做的事情也会越来越多。这是符合因事（一类事情）设岗的原则的。
2-2:公司的组织规模和成长阶段: 决定了IT部门的岗位设置及组织架构。
其实不仅仅是IT的部门，应该说公司所有的部门的构建都是由公司组织规模和成长阶段决定。
需求是一点点产生的，公司也是一点点成长起来的。职能部门是内部需求导向的。因为被需要才会有部门存在的价值。我想大家都经历过岗位逐步增长部门逐步发展的过程。
人、组织模式与岗位的关系我想很多人都会为这些问题困扰：
是因人设岗还是以岗定人？
是要建立横向岗位小组还是纵向协同小组？
2-3: 因人设岗还是以岗定人
因人设岗还是以岗定人看似两个相反的考虑方向，但是如果你把这两个对立起来其实想法就已经错了。这应该是两个相关因素。岗位跟人是无法分割开来考虑的。
举两个例子：
如果我们把几个类型的工作放在一个岗位当中，去招人的时候都招不到合适的人，你会怎么办？肯定就把几种类型的事情分开，把人先招进来。
如果公司起始的时候就是什么都要干，而恰巧有人都能干，而且因为公司小，工作量并没有到达所谓的饱和层级，那么我们会怎么做？那就先干吧，也不用考虑一定要分成两个岗位那么复杂。
当然，因为人是一个变化因素，而事情是一个确定性的因素，那么就事情来归类设置岗位会相对容易一些，以不变应万变。当然，这并不是绝对的。
2-4：横向岗位小组还是纵向协同小组
所谓横向岗位小组更像一种职能制组织架构。意思是把一类岗位的人放在一个小组。比比如把所有的基础（桌面）运维的人安排在一个小组。
而纵向协同小组，就是把基础（桌面）运维，系统运维，项目实施等各岗位放在一个小组，而同时有多个这样的小组。
其实这也没有一个绝对的标准答案。我的观点是这样的：首先还是看企业本身的规模和业务类型的复杂度。
如果是较为单一的业务类型和组织模式，可以建立横向的小组。针对具体的项目可以临时组织纵向的协同小组。
如果是较为复杂的集团型的业务类型和组织模式，那么适合建立纵向的协同小组去更好的贴合业务。当然，也不能忽略同一性质岗位人员的横向学习和知识共享。
3：思考问题的逻辑（Why-How到PDCA）
今天在召开部门会议，有几个同事发言，我总是想在大家的发言之后补充几句。后来发现因为很多小伙伴的发言上来就说某件事情是这么做的，对听者来说，经常会出现一个断层，因为不知道为什么要做或者说目标是什么。所以要把一件事情讲清楚或者想清楚，应该是一个从Why到How的过程。也就是我们经常说的来龙去脉。
今天我们沿着成功企业的顶层公式：企业成功=文化 x 战略 x 组织能力 来说说部门的组织及能力建设问题。
一个部门要建设成什么样子，是部门本身的问题吗？No，因为组织或者部门的存在本身是跟企业战略有关系的。所以，我们需要首先问Why？由Why引申出一个部门的定位问题。所以我喜欢在部门职责的第一句话是部门定位。尽管是一句简单的话，但写出来并不容易。
有了定位自然而然就是How的问题，我们应该怎么做。在讲具体做之前，也引入一个通用的PDCA的管理学方法。组织体系及能力的打造，其实就是一个PDCA的过程。意思是先P计划（策划），D执行，C检查，A找出问题，然后又回到P。
在做PDCA的时候，需要有个时间序列的维度。意思是从企业的整体运作来说，可以按照年度为一个大的时间节点，内部的具体事项根据需要可以再根据不同的情况细分节奏。
3-1：计划（策划），策划什么？
组织的策划，就是组织设计的过程，包括部门职责，部门内组织结构设计，人才结构设计。然后是岗位设计，岗位胜任力的设计，考核标准的设计。
这里的部门职责和岗位职责指的是根据战略对部门的要求（部门定位），部门具体要做的事。而对组织来说，这些事是具体要有人来做的，所以才会有胜任力及考核标准的事情。目的是为了用合适的人用正确的方法做好事情。
3-2：执行，做什么、如何做？
有了以上的标准，就可以开始进入一个循环。执行的过程就是做事情，来达成目标。要做的事情，从大的来说就是部门职责和岗位职责中描述的。当然，具体的事情如何去做，就每件事情来说本身也是一个PDCA的小循环。
3-3：检查？
检查其实很好理解，就是通过我们设定的考核指标来评判人的胜任力问题。
用胜任力和考核指标来评判某个人是否胜任这个岗位，这是一种结果导向的思考方式。
当然，检查并不是一个时间点，而应该是贯穿到过程中的。
3-4：之后的行动是什么？
检查的结果无非是做出决定并指导进入下一个循环。
如果是完全胜任的，应该被提拔；如果是能力不足的，应该被培养；如果是无法胜任的，应该被淘汰；如果是没有人来做这个岗位的事情了，应该招聘。
这里自然而然引申出了人力资源中讲到的选、育、用、流的很多具体的事情
3-5：组织体系，让一群人在一起高效的做事
过了年上来，手上的项目几乎都没有完全开始。所以近期听了阿里的组织建设课程，看了《华为的灰度管理法》。喜欢有体系的学习，有了体系就有了索引，可以把组织体系从头到尾梳理一下。
组织体系的建设包括设计和运营两个部分，具体包括：
业务分析：决定了组织结构要做成什么样子可以满足企业生存和发展的需求
组织设计：包括了部门职责和岗位职责的设定，以及人才的结构。意思是需要把合适的人放到合适的岗位上去为企业做需要的他做的事情。
建立对人的评价标准和考核标准：意思是怎么来持续评估这个人是否胜任？
持续做好人的工作，并根据组织需求进行提、培、换、招。
从业务分析到组织设计，是Why-How过程。所以即使同一个部门的名称，同一个岗位的头衔，在不同的组织中，职责都是不一样的。
以上内容是一个PDCA的管理模型。组织设计及标准的建立，是P的部分。
任何一件事情要做好，都有两只手。有一次在日本老师商品企划的培训课上听到有关Hard和Soft这两个词，很受启发。那么企业的生存和发展，在内部的组织体系建设中，上面讲到的就是Hard的部分，那么Soft是什么？我的理解就是企业文化的部分。
曾经思考过这么一个问题，我们什么时候需要做组织体系的建设？毕竟管理是有成本的。总结两个字：规模
当企业到达了一定的规模，就需要做组织体系的设计和建设。规模可以通过销售额来衡量，也可以通过人数来衡量。
所以有人说，华为在从10亿到100亿的增长过程中，是通过治理结构，组织力来支撑其增长的。而我们日常想到的是人多了必须要管，否则人浮于事、效率低下。当然还有很重要的一点就是老板的价值观，他的信仰。
4：组织的数字化
组织体系的建设离不开数字化，举一个最简单的例子，评价标准是一种客观的存在，这个客观通常是通过量化来实现的。
IT部门在大多数公司作为一个职能部门，它提供的是服务和产品两个部分。我们提供的网络管理，基础运维，系统运维，项目管理等等都是服务。而我们开发的用于企业日常运营的软件就是产品。大多数IT部门还是以服务为主。
根据之前讲到的IT部门组织建设中的各项内容，我们来聊聊IT部的日常运营，日常的运营应该说是分为人和事两个部分。今天我们讲事的部分。人的部分放到后面去讲。因为讲人必定会牵连到事，在组织体系中人是为做事情服务的，当然，过程中，人也完成了自我成长。所以组织和人其实是密不可分的。
IT部的日常运营，很多时候是跟软件和硬件打交道。这些都是运营的工具，IT部门跟其他部门不同的是，没有工具它是无法运营的，也是我们经常开玩笑说：IT部的每个人都应该是唯工具论的人，这是一种职业素养。但也正是因为这样，往往会给我们造成工具陷阱。对IT部门来说，工具也只是工具，光有工具是不够的，运营同样需要制度、规范、流程来保障，需要沟通协调。从某种意义上说，IT部更容易造成“人治”，因为很多被一般管理用于“法治”的系统、流程，在后台因为有了Administrator的权限，是可以被人为修改的。
在组织体系建设中，我们着重来讲讲运营-事与绩效挂钩的问题。
5：IT绩效管理
组织特定时间维度下的战略目标---（分解）---部门职责---（分解）---每条职责线特定时间维度下的要完成的具体工作---目标（绩效指标）---日常的事件运营过程和结果---（评估与绩效指标的偏差）---形成的绩效结果---推动下一轮改进计划及具体方法手段。
举例说明：
战略目标：公司在年度内的战略目标是要完成XXX销售业绩XXX利润指标。
绩效指标：在IT部的职能中一定会有保证各系统安全稳定运营这一项。这一项就是一个绩效指标。因为如果IT部门不能确保各类系统的安全稳定运营，那么就会影响到各业务部门的战略目标完达；因为如果今天邮件系统出故障了，业务部门无法按时与客户联系，如果今天业务系统出故障了，影响了销售的发货时效。所以，安全稳定运营就是一个绩效指标。
5-1：日常运营事项分解：
具体的事：
网络服务器巡检及定期的巡检报告的出具，问题的整改
防病毒系统的巡检和问题电脑的处理
安全意识的培训
具体的规章制度：
故障通报机制的建立
软件交付过程中的安全评估机制
安全设备配置调整的安全评级及审核机制
其实要确保安全稳定运营，这是非常难的一个指标。围绕这个目标，我们有些是用工具去做好防范工作，同时需要依靠人去对工具所检测的结果去进行跟踪处理，还要防范人为的失误等等。
要很好的完成这个目标，就是需要不断去主动防御，查漏补缺。所以从绩效角度来说，我们去跟进做了几件事情是毫无意义的。所以，相对比较适合做的是负向的指标。意思就是说无安全问题发生就是满分的绩效，而有安全故障发生，绩效直接做扣减。
当然，我们一直在强调，绩效的目的是为了改善，所以即使无安全问题发生，我们还是需要去做过程的跟进，意思是在过程中需要不断的去追问具体做了哪些防范的工作？这些工作够了吗？
5-2：思考
时间维度与绩效指标：
不同的时间维度，绩效指标是可以变化的。因为企业在不同时间维度下的战略是在变化的。
目标与绩效指标：
不是所有的职能目标都要作为绩效指标的。绩效指标的设定要符合简单原则。
绩效指标设定的两个方向：
绩效指标在设定的时候是可以有正向加分法和负向减分法两种的。指标的设定本身就是把运营量化的一个过程。
最后还是需要强调：在职能部门的日常运营和考核的过程中，追踪过程比考核结果更重要。
为什么是绩效
在组织体系的建设中，绩效是一个绕不开的话题。但我们应该知道，绩效的目的对企业来说是为了让团队步调一致的完成组织目标，同时也是帮助员工成长。
5-3：员工/组织/公司
一个组织一个部门，是一个团队，不是一个团伙。一个团队就需要有一致的目标，一致的行动准则。我们上面讲的部门职责、岗位设置是希望大家有一个共同的目标并分工协作以更高的效率去完成目标。绩效管理就是为了保障我们可以走在正确的路上。并且有一个对意识、能力、结果衡量的准绳。
员工如何与公司及部门一路同行？
A，通过企业文化及价值观，让大家想到一起。
B，通过绩效管理，薪酬福利制度，让大家做到一起。
C，不断提升员工的能力，让员工与企业共同成长。
绩效管理最大的误区
说到绩效，大家首先想到的是每月，每季度，每年度的绩效考评的分数，毕竟这是直接跟收入、晋升挂钩的。但这正是对绩效管理最大的误解。
绩效管理是为了培养和发展员工，而不仅仅是为了考核结果。
所以，绩效管理指标体系的设计和过程是我们重点要花费精力去做的事。指标体系的设计有方法有套路，但是绩效管理的过程却是因事而异，因人而异的。因为我们正是通过绩效指标，在过程中结合具体的事去帮助员工提升能力，达成绩效目标的。
5-4：职能部门的绩效体系如何来设计？
职能部门无法用销售业绩这样显而易见的指标来进行考核，所以很多企业最后的考核都成了形式。
通常意义上，我们有四种绩效体系可以参考：
OKR，目标与关键成果法；
PBC，个人业绩承诺；
BSC，平衡记分卡；
KPI，关键绩效指标；
我们究竟应该参考哪一种方法，这跟企业的战略、业态、价值观，人员的素质等都有关系。就传统企业的IT部门来说，可以结合OKR和KPI来进行。
我比较认同阿里的一句话：价值观好的员工绩效一定也会好。一味的通过制度和流程完善去实施管理，会造成事无巨细的固定思维模式而使得员工没有责任心。所以在指标体系的建设中，需要有价值观的部分，也需要有业绩的部分。围绕“量化”这个关键词进行。
价值观评价似乎是主观的，如何来“量化“？
这里的“量”大家首先可以考虑台阶，每一个台阶就是“量”，在评价是否到达这个台阶的时候，可以用具体的事情来印证和说明。具体的事情也是“量”（可以参考阿里的价值观考核体系）
业绩部分是可以直接“量化“的部分。
就IT部门来说，可以有正向和负向两种方式结合。
比如针对安全这样的指标，可以直接给一定的分值，如果出了安全事故作为负向的扣分方式。
正向的部分可以是项目，功能改善，培训，知识贡献等等。跟具体的流程和事项挂钩就可以量化起来。
从绩效的设计到过程是一个花费管理成本的过程，所以不宜太过复杂。
5-5：职能部门的绩效过程如何来做？
绩效的过程，也是一个PDCA的循环过程。
P：计划来源于目标。
D：过程中进行辅导。
C：反馈面谈，绩效考核。
A：达成共识，共同制定下一步改进计划。
这里的关键是辅导和面谈并达成共识。
针对结果，要对员工进行提拔、培养、替换、招聘。这是一个更大的循环过程。
6：IT部组织与职能
下决定来写这个系列的文章，是因为从之前招聘或者从技术培养IT部门的领导，很难。很少有人会有我这样的职业经历，从技术人到管理者似乎很难跨越，希望这系列的文章可以给大家一些启发。
在科层制的传统组织架构中，一般企业对部门的划分可以划分为经营性部门、职能（服务）性部门这两种类型的部门。对制造企业来说，也会分为经营性部门，研发设计部门，供应链部门，职能（服务）部门。但不管怎么划分，IT部基本上是归为职能（服务）部门。
企业战略被分解和落实到部门，才会形成部门的职责。意思是部门存在的价值是被战略落地所需要，为战略服务。就职能部门而言，大家很容易想到的是财务就是管好钱，人力资源就是管好组织和人。这就是传统的每个企业都会有的职能部门。那么问题来了，IT部门在企业中的职能究竟应该是什么？究竟应该干什么？这似乎是不太明确的。而且在我的理解中，IT部门的职能是随着企业的不同阶段，企业的规模，企业的发展战略而不断变化的，呈现出的内容或许会截然不同。
6-1: IT部的职能
当一个企业软硬件都很少，人数很少，规模很小的时候是不需要有IT部门的。我把软硬件放在第一位，因为IT的具体工作是围绕网络、服务器、终端硬件、系统、数据来展开的。所以，当这些很少的时候这个职能就可以忽略不计。
当一个企业到了一定的规模，有了网络、有了服务器、有了系统、有了数据，那么就需要有人来管。从企业战略分解的角度来看，对传统的制造、零售等企业而言（除非创新型公司IT承担经营性的职责），IT是战略落地的底盘，是为所有的部门提供更高效的完成战略目标的工具和抓手，是衡量整个业务及管理过程是否有效的抓手。
所以，我对传统企业IT部的定位是：IT部是一个IT规划和运营支撑的部门。
6-2: IT规划
IT的项目建设，数据积累是一个长期的过程，对企业来说投入巨大。所以IT的项目建设是需要跟随企业战略的落地去统一规划和分步实施的。这件事情并不容易做。因为一方面需要对战略和组织有充分的理解，要考虑战略和组织的发展，变化，需要有一定的灵活性又要保证连续性，对业务的适应性，还要适当考虑IT技术本身发展。
运营支撑：
所谓的运营支撑，基本上是要做好以下几件事情
A，安全稳定运营：
无论是网络、系统、数据、设备，这些日益成为企业运营的必备工具，智能设备越来越多的成为生产工具，那么确保其安全稳定成为最重要的职能之一。每个企业对系统的故障和宕机的容忍程度是不一样的，所以取决于企业对这些内容的依赖程度，来评估这个职能的重要性。
B，提升及规范运营效率：
网络、系统、数据、设备存在的价值是为了提升企业整体的运营效率。把“规范”这个词也加入进来，是因为在系统中走的业务流程，是固化的，起到了把企业制度及规范落地的作用。有了系统的规范，企业的日常运营才不会是人治而是“法”制。日常企业运营流程的规范化，本身就可以提升企业的运营效率，可以把事务性的工作交给系统去处理腾出更多的精力和脑力来关注异常。
C，IT软环境的建设：
任何的投入，企业都希望产出实效。如果我们把IT的项目投入，软硬件的投入作为一种投资的话，要产出实效并不仅仅在系统或者软件本身。
我打个比方，如果你买了一部手机，但你不会用，那么这个手机有价值吗？所以手机的价值并不是手机本身，针对智能手机，除了通讯基本功能外，通过各种APP，还给你带来了资讯，娱乐等一系列的价值。
那么，IT的软环境的建设包括了两个层级的含义：
让用户会用，了解基本功能，了解各种软件怎么用的。
更深层次的要告知用户，怎么要把一个业务问题，转化为一个数据可分析的问题来通过系统和报表、数据来跟踪和测量问题是否得到解决。
所以，IT软环境建设中一项具体的工作就是培训。
IT的职责和核心，无论网络、系统、数据、设备都All In One就是要产出实效。其实，效率也是实效的一个体现。
6-3: IT部门
在上面我们已经把IT部门需要承担的职能讲清楚了，那么IT部门是需要独立存在吗？或者说IT部门是要作为一级部门还是二级部门？
要回答这个问题，还是要回到战略落地和组织体系的构建问题上。组织体系的设计，也是要围绕更高效的完成企业发展和战略目标落地去考虑的。这还是一个效率问题。这里讲的效率是指组织内沟通和协调的效率。
当然就组织建设而言，因为有人的问题，所以不仅仅是理论上的组织构架，还要考虑的诸多因素。但组织要发展，构架就是应该随需而动。
部门职责落地数字化思考
部门职责落地，数字化要考虑两个方面：
一个是从目标设定到目标完达的量化。
一个是过程管控中的流程化规范化。
7：岗位职责
在公司的组织体系建设中，需要规划公司的组织架构。那么就一个部门来说，针对部门职责的落地，也需要对岗位设置进行规划
前一篇我们讲到了部门职责，根据企业战略的不同，战略的落地需要部门去承接，那么就会形成部门的职责。今天我们继续来谈谈岗位设置。从某种意义上来说，岗位应该是一个在组织中的最小单位。从扁平化管理的角度来说，甚至可以说不需要部门可以直接落实到岗位。以一个项目为例，项目往往会形成一些横向的临时性组织，那么这些项目组织就是以岗位组成的。
岗位设置不仅仅是岗位本身，还需要考虑岗位间的关系，也就是岗位图谱。
岗位图谱就是内部岗位间的关系，也包括对外连接的关系。决定了内部沟通对象及外部沟通对象。
岗位设置的原则究竟是什么，我觉得是一个核心和两个影响因素。一个核心就是围绕着部门职责的落地去展开的，就是我们常说的因事设岗。如果部门所要承担的职责无法有效的落地，那么再精巧的岗位设置也无用。两个影响因素一是成本效率，二是价值观。
7-1：成本及效率
岗位的多少和如何设置是跟成本及效率有关系的。这个成本效率其实有两层含义。一个是内部的成本效率，一个是外部的成本效率。
如何来区分内外，其实很简单，就是看同样做一件事情，是我们自己干成本低效率高还是请外面人干成本低效率高。成本和效率的衡量标准是时间和投入。
内部的成本效率如何来衡量？有一种说法，技术的深入度越高，效率越高，意思是专注于做同一类事情，孰能生巧，自然效率就高了。这个说法真的有效吗？对于简单劳动或许是有效的，但对于脑力劳动者来说，这个说法并不一定有效。因为脑力劳动者面对的环境和条件是在不断变化的，同时深度影响广度，必然导致沟通的效率低。如果我们把岗位设置看成是一张网络图谱，那么图谱中的节点越少，图谱就越简单，两点之间也就越容易通达。
当然，成本效率的考量我们不能仅仅停留在单一部门的角度，还需要考虑企业全体的角度。特别是IT是一个职能型的部门。
例如我们把基础运维的岗位外包了，看着似乎是合理的，因为这些基础的岗位社会化的服务成本一定是比自己有要来的低的，而且因为技术更专业化，问题的解决效率应该更高。但真的是这样吗？这里必须要考虑及时性的因素。而且，在做这样判断的时候，我们往往忽略一个很重要的因素，就是我们给出的标准的完备性。标准给出的越完备，内外的沟通效率就越高，反之会导致效率低下。
7-2：价值观
对于IT这样一个以知识型岗位为核心的部门来说，要绝对的来衡量效率在实际当中是很有难度的。所以，尽管成本效率从表面上来说是一个硬指标，但实际过程中，必然受到价值观这样的软条款影响。
企业的价值观，决定了岗位设置的偏向性。当然就岗位设置的本身来看，还有部门领导者的价值观问题。
所以岗位设置并不是一种僵化的东西。同一个行业，同样的企业规模，都是值得我们学习的对象。但要学的是内在的逻辑而不是表面的东西，毕竟没有一个完全一样的企业。
7-3：动态性
最后我们来聊聊动态性。就像组织架构设计一样，随着市场环境的变化，随着企业自身战略的变化，随着技术的不断进步，从部门职责到岗位设置都是需要有一定的变化和调整的。
这个动态性还产存在于岗位设置的过程中。我想很多人都会有这样的困扰，就是：是以人定岗还是以岗定人。其实我觉得大可以不用纠结这个问题。因为岗位定出来也是需要人去承担去做的。所以，这本身就是一个相互适应和动态匹配的过程。没有绝对的对和错，最后是一个平衡态。
在谈运营与管理之前，首先要搞清楚IT部门在组织中的职责和目标。部门的建设跟系统的搭建一样，是一个系统工程。在开始着手这个系统工程前，先要了解部门在整合大系统中（组织中）所处的位置。
IT部门是一个比较特殊的部门。从职能部门的角度来说，财务，人力，行政大家都脑子里会有一些印象，大概知道这些部门是干什么的。而IT部门，在很多组织中职责定位不尽相同。随着技术的发展，时代的进步，它的职能在不断的发生变化，具有动态性。部门的名字也有很多，有叫网络的，信息的，流程的，数据的等等。
所以，要管理好IT部门，要从组织对IT部门的定位开始，更要从对组织的了解开始。
对组织的了解，我的理解要从组织体系&战略目标，组织流程&职责架构两个方面切入。
7-4：组织体系&战略目标
IT部门可以是一个服务部门，也可以是一个运营的支撑部门，也可以是一个战略部门，也可以是一个经营部门。但在一般企业中，基本IT部门首先是一个花钱的部门。职能的性质并没有那么绝对，大多数制造企业的IT部门即是一个运营支撑部门，也是一个服务部门。哪个比重更大一些，是看组织对IT部门的定位，业务对IT系统的依赖程度，更多的也是作为一个部门领导的认知和扩展边界的问题。当然这个扩展，不是要满足部门或者领导的野心，是要看企业的需求和自我创造价值和创新的能力。
IT部门如果是一个运营支撑的部门，系统和数据就是它的一个工具和手段。
那么企业内部的管控模式是投资管控？战略管控？财务管控？还是运营管控？这些都决定了要如何搭建IT系统和如何去组织数据。管控模式越往下沉，管理的精细度就越高，对系统颗粒度的要求也会越精细。
日常从组织架构的职能部门架设中，我们也可以对管控模式，管理重点有所了解。
用IT的工具和手段去实现管理诉求，都是有成本投入的。作为一个成本中心，钱要花在刀刃上。那么我们就要了解组织的战略规划和战略目标。跟随战略规划和每个阶段的战略目标，把IT系统的建设和运营放在了一个动态的时间轴上。
公司的重点就在哪里，重点在哪里，资源就会在哪里。
7-5：组织流程&职责架构
企业的日常运营和管理，离不开职责，制度和流程。IT部门本身作为职能部门，内部的运营管理也是需要去梳理并不断制度化和流程化的。
很多时候，我经常会发现IT部门的人治是更胜于其他部门的。我们用系统和数据来变人治和法治，但我们自己往往陷入人治的更多，这里有认知、管理和工具的问题。所以，IT部门自身也要从人治到法治，并提高运营效率。
8：IT平台
平台是一个撮合者。以淘宝平台为例，一边是买家，一边是卖家。平台把两者联系在了一起，形成了交易，满足了双方的需求。
沿着这个思路，我们来分析一下IT部所要打造的平台。IT部的一边是公司内部的各个部门或者说业务单位，另外一边是提供系统的软件公司（暂时不考虑甲方IT部门自己开发提供软件）。IT部是把业务单位的业务需求，转换为一种软件需求或者说功能需求，然后寻找可以实现这个需求的软件或者软件公司，来实现这个需求，这样就在业务单位和软件公司之间形成了一次交易，一方面系统的实施，能够满足业务单位的需求，同时作为乙方的软件公司也完成了一次销售获得了收入。从这个角度看，IT的工作如果理解为平台，同样也是满足了双发的需求。
8-1: 平台的价值在哪里？
A-效率提升：
从购物平台的角度来说，买家和卖家是可以跳过平台直接交易的，那为什么还会有购物平台存在呢？平台存在的价值在哪里？我的理解平台的存在提升了交易效率，平台把商品放到平台上，并建立了某种规则，比如关键词搜索，可以让消费者更快的找到商品，同时平台也建立了一些规则和标准，让交易变得更透明公平。
那么作为平台的IT部的价值，也是提高了从需求到实现的效率。因为业务单位对系统是陌生的，而软件公司对特定企业的具体需求也是陌生的，IT部懂得系统，也了解本身企业的需求，所以IT部的存在是可以提升从需求到系统落地的转化效率的。
同时，IT部通过选型模型，项目实施方法论等工具，让这个交易变得更合规透明，用系统体系来保障项目成功落地。
B-数据的力量：
每一次成交，也就是说每一次一个需求被一个系统实现出来，会沉淀相应的数据。阿里都说自己是一个数据公司，IT部从某种意义上说也是数据公司，因为系统本身的运行沉淀了数据。如果IT部善于利用数据，数据被串联可以用于创造和激发更高层级的需求。甚至这个需求不是被提出来的，而是自然生长出来的。
8-2: 平台应该如何运营？
所谓的运营就是推动事物发展。平台只要做好三件事：提升认知；发掘需求；满足需求。
A，在传统企业中，大家对所谓的系统和应用是陌生的。如何消除距离感？首先要做的是引发兴趣，拉人关注。我们可以把这个理解为意识的灌输，需要通过不断的分享及培训去让大家认识到系统的价值。系统的用户或者功能的需求者也就是说公司内部的业务单位是你这个平台的流量来源。围观的人多了，自然会有需求。
B，善于发掘需求。需求可以是业务部门提出来的，但作为运营者要善于去理解和转化。业务部门提出的需求往往是为了满足或者实现它的一个目标，很多时候表面看似乎跟系统没有任何关系。但是如果我们理解业务场景，可以高于部门的表面需求去发掘背后的动因和目的。
C，找到合适的系统和供应商去实现和匹配业务单位的需求。任何的需求满足都是要付出代价的。还是以购物网站为例，在网站上有各种商品供买家选择，但是并不是所有的买家都能找到合适自己的商品的。所以，在万千的系统和供应商中，平台的价值就是用各种技术手段做精准的匹配和推荐，帮助业务单位找到合适的供应商和系统。
在平台被搭建起来后，平台的稳定运营和服务，必然会成为被关注的重点。我举个例子，如果淘宝整天不稳定，一会儿能上一会儿又不行，客户会很快流失掉。所以，IT部的另外一个底层的工作就是保障系统的稳定运营及安全性。
8-3:在运营基础上谈服务
我不是太喜欢把IT部门作为服务部门，而更愿意把IT部门作为平台的运营部门，运营产生价值，服务是平台滋生出来的一个长尾。
只有在运营平台本身产生价值的基础上，再讲服务，服务才更具有价值。如果把服务放在第一位，意思是如果只有服务的附加价值而没有平台本身的价值所在，那么服务是无本之末，价值度是无法被真正认同的。
当然，服务是必须要做好的，因为服务做好了才会有下一次的交易机会。
如果从运营的角度来理解IT部的工作，IT部还是一个技术部门吗？NO，它首先是一个运营部门。运营部门的核心是策划，推动事物发展，技术只是实现交易的一个工具，或者说是IT部作为平台提供的一个产品。
8-4: 运营运作
我把每个部门的日常运作叫做运营。运营的目的是为了完成组织绩效。在上一篇中我们讲到了绩效的过程是一个PDCA的循环过程，那么这个循环就是通过日常的运营来推动的。一个部门如此，一个组织也如此。
运营就是对运营过程的计划、组织、实施和控制，是与产品生产和服务创造密切相关的各项管理工作的总称。从另一个角度来讲，运营管理也可以指为对生产和提供公司主要的产品和服务的系统进行设计、运行、评价和改进的管理工作。
用管理的方式方法来实施IT项目
最近在实施IT项目过程中经常听小伙伴讲到IT软环境的问题。IT系统要产生实效跟使用人有关系，而在IT基础比较薄弱的环境中，也就是我们说的软环境较差的企业要实现数字化科学化的管理，就会遇到鸡和蛋的问题，起步就比较难。那我们要用什么样的手段来实施项目呢？今天抛出这个话题跟大家探讨。
8-5：从项目目标到项目实现
有人提出，“如果企业软环境比较差或者说项目目标不明确就不要实施项目，如果项目目标是明确的，那这个就不是问题。”
这个问题有点尖锐，在非黑即白的IT世界中似乎很有道理。但往往从起步到目标实现是一个过程，一个逐步迭代的过程。在互联网的公司有怎么一句话：“只要方向正确”。但往往现实并不是方向正确就可以，就具体来说是“具体什么目标?如何实现?要克服多少障碍?”。所以这个共识并不是那么容易达成的。
用管理的方法来实施项目
在很多年前就听到过这么一句话：“要用搞运动的方式搞项目”。经过那么多年，终于有所体会。对此总结以下四点：
A，领导支持不可少
这点做项目大家都知道，但如何获得领导的支持，并不是每个人都会的。
首先需要可执行的完整方案，核心是告知领导打算怎么去实施这个项目。过程中如何去宣导，培训，跟进，检查督导。期间需要领导去帮助做什么？
调动领导的资源很多时候是双刃剑，要珍惜每次的机会。
B，策划和计划很重要
在项目管理方法论中，有一个非常重要的方法，就是工作分解结构（WBS)。
项目---任务---工作---日常活动。
在IT项目的实施过程中，搞技术的人员习惯性的思路是通过技术去解决问题。这个在项目实施过程中是需要的，毕竟IT项目有技术（软件）实现的部分。但在WBS中，我们必须要引入策划或者说管理的方式方法。
C，策划
策划是一个有输入和有输出的过程。
具体在IT项目中，策划输入是一个项目环境评估过程。包括组织架构，业务流程，各级领导对数据化管理的认知水平（业务分析报表的完整性），原有系统的使用情况，可以利用的人、财、物的资源等情况。
策划的输出核心是一个解决问题的过程和呈现的结果。核心围绕需求是什么，如何实现需求展开。
D，计划
有了策划接着就是一个计划的过程。在计划中引入了时间维度和阶段性的度量维度。比如说在策划案（解决方案）中，我们希望通过培训去提升认知，那么在计划中就要有培训环节，什么时候培训，培训什么内容，达到什么效果。
项目的实施是有时间限制的，这是项目管理的约束条件之一。IT类的项目，因为是“软”的，所以项目进度往往拖延，其实核心的问题还是项目计划做的不够完备，当你都不知道在这个项目有这么一个过程或者一个动作，当你没有能力去预估这个过程或者动作完成需要的时间，那么计划是永远无法按期完成的。
E, 特别提醒
项目的实施过程往往是多方配合的结果，不能仅以自己的理解或者行动能力去评估项目时间，这也是为什么前期要有个策划和评估的过程的原因。
F，过程，一个也不能少
整个项目实施的过程，除了前期技术实现部分的配置，开发，测试等环节。在上线环节中，还有不断的培训，调整，改善，考核，监督检查的过程。
这里需要各种文档、制度、规范去落地实施。包括沟通会议机制，各种编码规则，作业指导书，各类表单，各类记录文件，操作手册，培训文档等等。
G, 备注
A，对需求变更及项目边界的控制。
B，有稽核有辅导，从陌生到习惯：从培训到督导检查到调整改善的PDCA小循环需要长时间高密度的去做，高频次是养成习惯的必要条件。
8-6: 弯下腰、低下头，干好事
打仗的时候说：“只有在一线才能听到炮火”。
同样的，做项目的时候要记住：“只有在一线才能了解细节”。
到一线去，深入现场，成为他们的一员，带着好奇心，去问问题，去亲自试着做一做，才能让系统更贴合业务，才能把细节做到位。
,
