做企业信息化主管这些年我有一个很深的感触这个岗位在公司里的位置相当微妙。老板觉得你是“搞IT的”业务部门觉得你是“管系统的”下属觉得你是“审批流程的”只有你自己知道你其实是在一座由老系统、新需求、历史数据和复杂人际关系堆成的山上一边修路一边开车。很多人问我信息化主管到底要干什么要会什么说实话招聘网站上写的那些职责描述和实际工作里真正要面对的事差距大到像两份完全不同的职业。这篇文章我就结合自己带团队、做项目的实际经历把信息化主管的职责拆开揉碎讲清楚顺便聊聊那些踩过坑之后才明白的能力要求权当给同行或者准备往这个方向走的朋友一份参考。1. 信息化主管到底在管什么一张职责全景图1.1 职责不是“所有IT相关的事”而是五件事刚做信息化主管的头半年我一直有一种困扰就是每天都被各种琐事推着走。网络不通找我打印机卡纸找我ERP出不了报表找我甚至业务部门换电脑也找我。当时我觉得自己就是个超级运维直到有一次公司做战略复盘老板问我“你这一年除了修电脑和保障系统别崩还干了什么”我才被问醒了。后来我带团队给底下的人定职责也给自己重新梳理了工作边界。信息化主管的职责不管公司规模大小、行业是什么压缩到极致就是五件事定方向、管选型、控实施、保运营、促变革。定方向是规划这个阶段要搞清楚公司未来两三年业务要往哪走信息系统要提前布局什么管选型是决策自研还是外购买哪家产品花多少钱用什么节奏上控实施是项目管理需求调研、蓝图设计、上线切换、问题修复一环扣一环保运营是常态系统稳定、数据准确、安全合规、用户支持促变革是最难的一环系统上线不等于业务落地要推动大家真正用起来把流程优化落到实处。你可以把这五件事理解成一个环没有规划选型就是碰运气没有选型实施就是无源之水没有实施运营就没有对象没有运营变革就是一句口号。很多信息化主管之所以累就是因为只做了中间两环甚至只做了第三环和第四环的一部分规划和变革全被丢掉了。老板问起来为什么系统价值不明显答案就藏在这里。1.2 与CIO、IT经理、信息专员的分工边界还有一个容易混淆的问题就是信息化主管和CIO、IT经理、信息专员之间到底是什么关系。我见过不少公司把这几个头衔混着用但实际上岗位重心差很多。从分工来说CIO是决策层面对的是董事会和CEO思考的是信息化如何支撑企业战略怎么用数据和技术重塑商业模式信息化主管是执行加管理层面做的事情是把战略拆成项目把项目拆成人力和预算确保按期交付且不炸雷IT经理往往更偏向日常运维团队管理管着网络、服务器、桌面支持这些人信息专员就是具体干活的人可能是开发工程师、运维工程师、实施顾问。我在一家中型制造企业的时候上面没有CIO我直接向分管副总汇报那我的角色实际上就是半个CIO加一整个信息化主管。你要能跟老板讨论数字化蓝图也能卷起袖子给系统做数据修整。这种“一岗多能”的状态在中小企业特别常见所以我不太建议大家死抠头衔更重要的是看责任边界。你手上有哪些资源要扛哪些指标踩了谁的线这是需要跟老板明确谈清楚的。另外我建议大家不论公司有没有CIO信息化主管一定要养成写“信息化年度报告”的习惯。不要等到年终总结才想起来算系统运行率每个季度都把系统健康度、项目进度、业务反馈、下季度计划整理成一页纸给管理层看。这样做有两个好处一是让老板知道你在干什么价值可视化二是倒逼自己从具体事务里抽身站在全局看问题。我自己坚持了三年效果非常明显——至少老板不会再问你天天在忙什么了。2. 能力要求技术、业务、管理三分天下2.1 技术视野不写代码但不能看不懂技术底牌做信息化主管要不要懂技术很多人纠结这个问题我的回答是你不需要是技术大牛但你必须具备技术判断力。换句话说你可以不亲手写代码但你必须能看懂技术方案背后的逻辑知道这个技术大概怎么实现的、有什么坑、是不是过度设计。有一次我们要上新的MES系统厂商A报的方案里用了一堆花哨的技术名词区块链、微服务、大数据中台听起来特别厉害厂商B讲的是怎么和现有ERP对接、怎么处理断网续传、车间老设备怎么采集数据非常朴素。我当时的团队里有个刚入行的同事说A方案听起来更有远见我让他去查了一下A厂商的客户案例发现这家公司在我们的行业里根本没有落地案例那些概念基本是拿我们当试验田。最后我们选了B系统上线至今运行非常稳定。这里面的判断依据不是谁的技术名词高级而是技术跟业务场景匹不匹配。信息化的历史很典型可以类比成盖房子信息化规划就是画图纸系统建设就是打地基砌墙数据治理就是通水电网络AI应用就是后期做智能家居。没有前面的基础直接上智能家居结果只能是买个花瓶摆着看。所以我一直要求自己保持对技术的好奇心但不追新、不盲从。每看到一个新技术方案我都会问三个问题它解决了什么业务问题它的风险在哪里如果不用它有没有更简单的方式这三个问题也是我给团队培训时必讲的内容。2.2 业务理解与翻译能力信息化主管最值钱的软技能我发现很多IT人转型信息化主管最大的瓶颈不是技术而是听不懂业务。业务部门跟你说“我们要一个能实时看到库存的系统”你以为就是报表加个刷新按钮结果人家真正想要的是“业务员下单的时候系统能自动判断仓库是否有货没有货就提示替代料”。这种需求的错位导致了一个很普遍的现象——系统功能明明做了业务部门说不是他们想要的实施顾问说业务部门自己没说清楚两边互相扯皮。作为信息化主管你的核心价值就是做“翻译官”把业务语言翻译成系统需求再把系统能力翻译成业务价值。这个能力怎么练没有捷径就是多泡在业务现场。我做信息化头两年几乎每天都要去车间、仓库、销售办公室转一圈不光是跟部门负责人聊更多是跟一线操作员聊。他们不会用术语只会跟你说“我做这张单子每次都要黏三张表格”“月底对账的时候老是差几毛钱”。这些抱怨才是最真实的需求来源。包括对信息的理解很多人觉得信息就是数据其实信息是数据经过加工之后对决策有意义的内容。系统里存着销售流水是数据经过分析发现华东区退货率异常升高这才是信息。化主管要做的就是把数据变成信息的加工厂而不是数据仓库管理员。2.3 项目管理与跨部门协调三分靠技术七分靠沟通如果说技术能力决定了你能不能把事做成那沟通协调能力就决定了你做事的过程顺不顺。信息化项目有一个先天的矛盾你管着预算和进度但干活的资源大部分在业务部门手里。你催业务部门梳理流程他们说业务忙你催供应商赶工他们说需求不明确你向老板汇报进度老板问为什么又延期了。夹在中间的滋味没做过项目的人很难体会。我后来总结了一套自己的打法分享给团队效果还不错。第一项目启动会一定要请最高层领导站台哪怕只是讲话五分钟这代表了一个信号这个项目不是IT部门的事是公司的事。第二每个关键节点必须有业务部门负责人签字确认比如需求规格说明书、蓝图设计文档签字就意味着他们认可后面需求再变就不是你单方面背锅了。第三每次项目例会的会议纪要必须抄送给所有相关方包括老板。不要小看这个动作很多问题背后其实是信息不对称白纸黑字能挡掉一半扯皮。沟通还有一个底层逻辑就是别总拿系统说事要拿业务痛点说事。你跟业务部门说“系统的接口标准要统一”他们不关心你跟他们说“如果不统一接口以后每个月手动导一次数据大概会占用半天时间”他们立刻就上心了。信息化主管要学会算账用业务听得懂的语言争取支持。2.4 成本意识、供应商管理与风控底线除了技术和业务还有一项能力容易被忽视就是经营意识。信息化的每一项投入本质上都是企业投资你要对投资回报负责。我见过有些同行选型的时候只盯着软件授权费忽略了实施费、年维护费、二次开发费、硬件升级费结果项目进行到一半发现预算超了一大截只能砍功能或者东拼西凑留下一个半残系统。我现在做预算一定会按一个公式来估算整体拥有成本软件授权费用加实施服务费用加年度运维费用加内部人力投入加硬件网络改造费用再预留百分之十到十五的不可预见费。这个公式看起来简单落到实处能避免很多尴尬。另外供应商管理也是一门学问不少人以为签了合同就万事大吉其实合同里关于验收标准、交付清单、人员资质、违约责任的条款基本决定了项目能不能顺利收尾。风控这块我的原则是上线的系统可以不够先进但权限和审计边界必须清晰。特别是涉及财务、客户、供应商这类敏感数据谁能在什么条件下看什么数据必须有一张权限矩阵并且在系统里做到严格落库。这条底线守不住总有一天会变成事故。我自己就碰到过因为离职员工账号没有及时禁用导致内部数据被拷走的案例虽然最后没有造成特别大的损失但那一阵子的压力至今印象深刻。3. 实操实录从信息化规划到落地的5个关键环节3.1 第一步信息化现状诊断与需求收集很多信息化主管年轻的时候容易犯一个毛病就是上来就想搞个大动作。老板说今年要上ERP第二天就约几家厂商来看系统然后挑一家就开始干。这种做法的成功率说实话不高。原因很简单你没有搞清楚自己家里的地基是什么状态就着急买精装房结果往往是要么精装房放不下你的旧家具要么管线跟老房子的水电根本接不上。我现在做任何一个信息化项目第一个阶段一定是免费但极其重要的现状诊断。这个阶段通常用两到四周时间做三件事梳理现有系统架构、梳理核心业务流程、收集关键用户痛点。梳理系统架构比较简单画一张系统关系图把当前有哪些系统、谁在用、数据怎么流、接口怎么打通列清楚业务流程梳理要难一些需要把所有部门的骨干拉在一起把从订单到回款、从采购到付款这种主干流程从头到尾走一遍每个节点问三个问题“这一步是谁做的”“需要什么数据”“输出给谁”用户痛点收集反而是最轻松的因为大家抱怨的意愿往往非常高你要做的只是把这些抱怨分类整理去掉情绪化的部分抽取本质诉求。需求收集阶段有一个很有用的方法论叫“用户故事”别看这个词听起来新潮实际操作上就是让用户描述“我是谁、我要干什么、为什么”。比如销售说“我是销售员我要在客户现场快速查库存因为有时候晚了半小时单子就被竞争对手抢了”。这样一条用户故事比业务部门写十页需求文档对你的帮助都大因为它自带场景和价值判断是信息化主管决定优先级的重要依据。3.2 第二步供应商选型与POC测试现状诊断做完了对需求有了清晰认识才进入选型阶段。选型是所有信息化项目里最不能拍脑袋的环节我自己的经验是只看PPT和产品演示基本等于盲人摸象。厂商来给你演示产品的时候用的是精心搭建的演示环境里面的数据、流程都是提前准备好的你看着赏心悦目但根本无法判断这套系统放到你的业务场景里是不是同样顺畅。所以我坚持要求所有候选厂商做POC测试也就是在真实场景里跑关键流程。当然POC不要贪大选三个最核心的业务场景就够了比如制造企业就测生产工单下达和领料流程贸易企业就测订单管理和库存同步。POC期间你要安排厂商对接你公司的真实数据让一线用户亲自操作你在旁边看他们的反应。用户说好用那才是真的好。选型评分表也很重要我习惯把评分维度分为四块每块权重不同功能匹配度占四成技术架构占两成实施团队能力和案例占两成价格和商务条件占两成。注意实施团队能力和案例这一项非常重要但很多企业会忽略。软件产品是标准化的但实施顾问是靠人做的同一个产品两拨顾问做出两种结果的情况我见得太多。签合同之前一定要在合同里锁定核心实施顾问名单并且写明如果中途换人需要你书面同意。这一条写进合同后面能省掉你大量麻烦。3.3 第三步实施范围控制与变更管理选完型签完合同看起来大功告成其实真正的战斗才刚刚开始。信息化实施的过程里需求变更是最大的进度杀手。业务部门今天说这个字段要加明天说那个流程要改每个需求看起来都不大但累积起来轻则上线延期重则系统做得四不像。我处理需求变更有一套标准动作。所有变更请求必须通过书面或者线上工单提交不能口头说一下就改接到变更请求后先做影响分析改这一块要影响几个模块、要延长多少工期、要增加多少成本分析完以后给业务部门两个选项要么接受新增工期和成本要么放到二期再做。大部分需求其实没那么紧急你一给选择对方自己就会评估真正重要的需求自然会坚持无关痛痒的也就算了。这套机制不是卡用户而是保护所有人因为一个没有边界的信息化项目最终的受害者是整个项目组和买单的老板。上线切换策略也很考验主管的经验。现在很多人谈“一刀切”色变觉得大爆炸式切换风险太大全部倾向并行上线。但并行并不一定就更安全双系统运行期间用户要重复录入数据抱怨很大而且两边数据不一致的时候核对起来非常痛苦。我在制造业实施ERP的时候试过在一个车间先跑新系统跑顺了再逐步推广效果不错。上线切换没有绝对正确的答案核心原则是控制风险和减少重复工作之间的平衡你要根据系统的复杂度、用户的接受度来选并且提前准备好回退方案。3.4 第四步数据迁移与用户培训实施阶段有两个脏活累活看起来不起眼但做不好就是以后天天遭罪的根源一个是数据迁移另一个是用户培训。数据迁移说白了就是把老系统里的数据搬到新系统。这个过程的枯燥程度让人怀疑人生但出问题的影响却相当大。新系统上线后库存不对、财务对不上账十有八九是因为数据迁移出了问题。我做数据迁移有一条铁律——必须先做数据清洗再迁移而不是原样搬运。老系统里那些重复的客户记录、错误的基础档案、已经失效的物料编码全要在迁移之前清干净。否则垃圾进垃圾出新系统运行的第一天就继承了老系统的病根。清洗完之后还要做数据验证这一步我再强调也不为过迁移完的数据和原系统的数据要抽样做核对库存金额、应收余额、未结订单这类关键数据必须对应上账本不能凭感觉说差不多了。用户培训则是另一个大坑。很多厂商的实施顾问把培训做成“演示一遍PPT再操作一遍系统”就算完了效果可想而知。真正的用户培训必须分岗位来做让用户在自己真实的职责界面里操作真实业务的模拟数据练习完之后还要进行考核考核不通过不允许上岗。关于培训我想劝各位信息化主管务必要争取业务部门的配合。你千万不要自己一个人去搞定所有终端用户的培训而要先培训各业务部门的“关键用户”这些人通常是部门里业务熟练、又对电脑系统接受度比较高的骨干让他们成为你散布在各业务部门的“基层教练”后续日常问题先由他们消化一轮解释不通的问题再反馈给IT团队。这个梯队一旦建起来你的运维压力至少降一半。3.5 第五步上线后的运营与迭代系统上线不是终点最多只能算是系统生命的起点。很多公司把大量资源花在选型、实施上上线之后项目组一解散IT团队就进入被动救火模式业务部门报一个问题处理一个系统就停在刚上线的状态再也不成长。这种“一次性项目”思维恰恰是信息化价值无法持续兑现的原因。我习惯在上线之后拉出一个为期三个月的“优化期清单”来持续迭代。第一个月重点是稳盯系统性能、数据准确性、用户操作反馈把稳定性问题先清干净第二个月重点是顺根据用户实际使用的情况优化操作界面和流程节点去掉那些在蓝图设计时看起来合理、实际却很繁琐的多余步骤第三个月重点是深和业务部门坐在一起复盘哪些环节因为系统上线发生了变化哪些管理报表可以做得更智能把这些需求整理成二期项目。运营期的核心指标我不看那些虚的就看三个数系统月活跃率也就是有多少用户在用关键流程平均处理时长跟上线之前做对比未及时关闭的工单数量。这三个数是业务管理层最能感知价值的指标比跟老板讲“我们采用了什么先进架构”有用一万倍。信息化主管要记住只会讲技术的领导价值感很低能讲系统给业务带来多少改进的领导才有资格进管理层核心圈。4. 常见问题与排查技巧实录4.1 预算不够怎么办分阶段推进的取舍逻辑几乎每个信息化主管都会遇到预算不足的情况尤其是第一年老板说“你先规划钱后面再说”。如果你满怀理想地掏出一份包罗万象的三年规划我保证老板会看晕然后项目就没然后了。预算有限的正确打法是分阶段推进。第一阶段只做最痛的那件事比如现在手工做库存台账经常出错那就先上库存管理模块把数据管准让业务尝到甜头第二阶段再往周边扩库存准了采购和销售流程自然需要跟上上了采购和销售ERP的骨架就出来了第三阶段再考虑财务业务一体化、生产管理或者数据分析这类深水区。每一步都有明确收益老板才愿意继续投钱。如果连第一阶段的预算都很紧张那还有一些变通办法。比如考虑按年付费的SaaS产品把一次性的大额支出变成运营费用虽然总成本不一定低但决策压力小很多或者与供应商谈判分三期支付按照项目节点付款绑定实施效果。我在遇到预算困难的时候有过一次很成功的经历第一年只花了十几万在某业务痛点上做深度应用第二年项目产生的节省金额远超投入第三年老板主动问我要不要再扩大范围这就是典型的用价值换预算。4.2 业务部门不配合先解决谁的问题业务部门抗拒新系统是信息化推进里最让人头痛的事。表面原因千奇百怪有人说系统不好用有人说增加了工作量有人干脆说自己年纪大学不会但底层的逻辑其实很简单他没有看到系统对他个人有什么好处反而先看到了威胁或者麻烦。我处理这类问题的思路是先找到那个最配合你、又最容易被业务认可的“突破口”。有一次推广OA审批流行政部反馈他们每个月要跟进几百个审批单一个个催常常有人拖一两周不回我就先解决“催办提醒”这个痛点让审批超时自动提醒待办人直接帮行政减少了工作量。行政部用得很顺心自然就成了OA系统在公司的宣传员其他部门看到行政用得好态度就软化了很多。与其你天天跟业务部门强调公司层面的价值不如先让某个群体的个人工作轻松一点口碑就像滚雪球一样滚起来了。还要注意一个细节就是干活的永远是基层操作员但拍板的是部门负责人。你如果只搞定了部门负责人下面的员工消极应付系统数据照样一塌糊涂你如果只讨好基层员工部门负责人觉得没有掌控感项目也很难推进。理想的做法是变革之前让部门负责人当“项目发起人”变革之中让关键用户当“应用标杆”变革之后把部分的绩效指标跟系统数据挂钩这样所有人都能从项目里得到他们想要的东西配合度才可持续。4.3 供应商拖工与扯皮把验收标准写进合同软件实施项目的延期率有多高做过的人都清楚。供应商总是有一堆理由需求变更了、你们内部配合不及时、你们的数据不干净、你们领导签字慢。有些理由是真实的有些是借口但站在信息化主管的角度核心问题往往出在合同没有写清楚边界和验收标准。我记得有一次签一个合同当时注意力全部放在软件功能和价格上验收条款只写了“系统上线并稳定运行一个月后组织验收”结果呢供应商把系统部署上了说是上线了但经常报错。他们一口咬定已经上线要求支付验收款我们觉得这系统根本没法正常工作坚决不给。后来翻了合同才发现确实没有约定“稳定运行”的定义和验收标准搞得双方僵持了很长时间。这件事之后我的合同里对于验收一定明确写清楚几项内容关键功能的验收标准比如单据保存时间不超过两秒、月末结账可以在十分钟内完成上线的核心指标数值比如库存准确率达到百分之九十九点五以上缺陷的等级和修复时限致命缺陷必须几天内修复一般缺陷允许滞留多久验收流程是业务部门参与测试、签字IT部门出具技术复核报告最后才进入正式验收阶段。经验总结起来就一句话不要在合同里用“完善”“稳定”“满足要求”这种模糊词数字化时代的一切标准和指标全都落到数字上。4.4 系统上线即“信息孤岛”主数据治理从哪里开始很多公司上了一堆系统后发现销售系统不知道生产系统的数据财务系统跟业务系统对不上大家像是各自住在自己的岛上数据传输靠线下邮件和Excel表。这种现象被贴上了一个时髦的标签叫信息孤岛但根源通常只有一个——主数据没有管好。主数据就是那些企业核心业务对象的基本信息包括客户、供应商、物料、产品、组织架构、人员等等。这些数据分布在各个部门有各自的编码体系甚至同一个客户在A系统叫张三公司在B系统叫ZHANGSAN CO., LTD.数据不统一系统之间天然无法对话。我建议做主数据治理不用一步到位先选其中一个最核心、最捣乱的领域开刀。对大多数企业我建议先做客户主数据或者物料主数据因为这两个字段是销售、采购、库存、财务全链路都会用到的。我把这个工程称之为“给公司所有客户建统一的户籍档案”从编码规则、录入规范、审批流程、系统权限到清洗规则全部标准化再通过接口同步到各个业务系统。做的时候很枯燥但做完之后你会发现不仅系统之间的接口好做了连日常管理报表的准确性都大幅提升。互联网上谈信息的价值常常强调连接和采集但实际上连接的前提是把数据标准统一好不然连了也是错的。4.5 权限失控与安全风险最小授权原则的边界财务、业务、管理层各角色对系统的访问权限从来都是信息化管理里最敏感的雷区。我见过一家公司因为操作权限混乱一个基层库管员居然能看到全公司的采购价格虽然没有造成什么恶劣后果但消息传出去之后采购部门跟供应商谈判的时候尴尬到了极点。我现在管系统权限遵循的就是最小授权原则每个人只拥有完成本职工作所需的最小权限集合。这个原则的分寸感在于权限不能太宽宽了有数据泄露风险但也不能太死太死了业务跑不动。比如销售总监需要看到全团队的业绩数据但不需要看到每个订单的底价财务总监需要看全公司的预算执行情况但不应该能直接修改业务单据。放权还是限权我给每个岗位设完权限矩阵之后都会让部门负责人过一遍问一个问题“你部门里这个岗位有哪些数据是坚决不能看到的”通常这个问题比“需要看到什么”产生更清晰的答案。权限的生命周期管理也要跟上不能员工调岗了、离职了权限还在老地方挂着。我要求团队每个季度做一次账号权限复核对所有高权限账号进行专项审查配合HR的离职流程给离职员工当天做账号禁用。这听起来很基本但我敢说很多公司在这一点上其实长期存在漏洞。5. 分享一下我带新人、带自己的一些心得关于信息化主管这个角色我想再补几句个人的心得体会不一定适用于所有公司但应该能帮你少走一些弯路。第一你不可能让所有人都满意。信息化项目本质上是流程再造它一定会动到某些人的奶酪会打破一些旧有的舒适区。你想让所有部门都喜欢你那系统大概率会变成一个谁都不满意的妥协产物。我的经验是做正事之前先做好利益相关者分析明确谁是支持者、谁是反对者、谁是摇摆者把主要精力放在支持者和摇摆者身上反对者用制度来约束而不必试图讨好所有人。第二新官上任不要急于点火。我见过不止一个同行到新公司上任之后三个月内就急着启动大项目结果连公司的人际关系、权力结构、业务流程都没摸透项目最终成了炮灰。我自己后来的做法是前三十天只访谈、只调研、只做内部梳理不动任何系统不发任何建议方案把耳朵竖起来听把笔记写满然后才开始慢慢地、温和地提出问题。这样下来我提出的建议被采纳率反而高了很多——因为你说话的分量不取决于你多聪明而取决于你多了解情况。第三你要找到一个能替你说话的“老板支持者”。信息化建设一定是老板工程没有高层支持很难成事。这里的老板不一定是CEO也可以是某个真正重视数据和管理规范的高管。你要让这个支持者清晰地理解你的规划逻辑每次阶段汇报都把变化和成效整理成容易传播的业务语言交给他让他能在核心会议里替你发声。有了这个支持者你就不用每次都自己冲在前面当恶人。信息化这条路说实话挺苦的。它不像销售那样签单立竿见影也不像研发那样有明确的产品里程碑更多时候是在做那些别人看不见的地基工程。但如果你真正想在这个领域深耕锻炼出来的业务洞察力、统筹能力和数字化判断力放到任何行业都有很强的迁移价值。希望这些踩过坑之后的思考能对正在这条路上摸索的你有一点帮助。