1023.BPM项目立项审批流程
BPM项目审批卡了仨月？这10个坑你绝对踩过
搞了三个月，连个BPM立项都没批下来？
别笑，这事儿太真实了。
我见识过数目众多的团队, 满怀壮志豪情打算推行BPM, 可是, 他们的PPT修改了十七个版本, 会议召开了二十三次, 然而, 老板的批示却始终停留在“再去研究研究”。你可明白那种感受吗? 恰似你憋着一股劲儿想要奋力冲刺, 却惊然发觉鞋带已经被捆绑在了原地。
实际上讲, BPM项目展开立项以进行审批这个事情, 整体自身就是一回针对流程的那种“流程审判”活动。
试着去思索 , 在BPM项目立项审批这件事情上 , 其目的究竟是什么? 难道是为了对风险加以把控吗? 又或者是为了将投资回报明确下来? 亦或是仅仅单纯地只是为了 “走过一个流程形式 ”而已?
为什么你的BPM立项审批总被卡？
第一，你根本没搞清楚“批什么”。
很多人以为，立项审批就是批“要不要上BPM系统”。
错。
要是你这么去想 , 那可就等着被各个部门的老大狠狠怼死咯 , 业务部门会追问: “眼下这东西究竟能不能成功解决我月底报表难以弄出不报的状况? ”财务部门会发问: “投资回报率究竟是多少呀 , 按此实行半年是否能够把本钱就收回来? ”老板会质问: “这难道又会是 IT 部门想要瞎折腾一番的想法吗? ”。
在你一张嘴, 讲出“我们要上BPM”这话时, 对面瞬间就连连抛出十个问题, 并且你对其中任何一个都没办法做出回应。
关于BPM项目立项审批, 其核心所涉及到要审批的内容, 实际上是三件事情, 是什么呢? 就是那业务痛点究竟是不是足够痛, 那解决方案是不是足够精准, 以及资源投入到底值不值得。
疼不疼, 并不是由你去判定, 而是由业务部门加班直至哭泣的同事来判定。可不准, 需要凭借历史数据以及行业案例来讲明。划不划算, 你必须将账目算到他的心坎当中。
第二，你写的立项报告，像一份“产品说明书”。
唉，太常见了。
到处都是“功能强大”, 到处都是“流程优化”, 到处都是“效率提升”。我瞧着就犯困, 老板瞅着就想发火。
你仔细去思索一下, 老板在一天当中要阅览多少数量的报告? 你所呈上的那份BPM立项审批报告, 要是没办法在30秒这个时间范围内吸引住他的目光, 基本上就会被丢进垃圾桶之中了。
怎么做那个书写呢? 来讲故事, 讲一个真实的故事, 这个故事是因流程的混乱, 造成客户投诉, 致使订单丢失, 还导致员工离职。讲一个血泪史, 这血泪史是因审批缓慢, 错失了市场机会, 叫被竞争对手甩出去三条街。
当前情绪状况欠佳的话, 立项工作将会徒劳无功。针对这种情况, 你所撰写的报告当中, 务必要包含部门所发出的“惨叫”以及“愤怒”之情, 而绝非是那种缺乏温度的技术参数。
关于审批节点的那些“潜规则”
BPM立项到底要经过多少个节点？
这问题我没办法给你一个标准答案，因为每个公司都是奇葩。
存在这样一些公司, 部门的老大仅仅签个字便算完成, 其速度快得如同外卖配送一般。还有另外一些公司, 需要历经部门初步审核, 以及分管副总的再次审核, 并且要有跨部门的联合签字, 还要经过法务合规方面的审查, 以及财务预算的评估审定, 最终还得经过CEO的最终批准……仅仅看这样的流程, 就足以把你弄得焦头烂额的。
但, 我能够向你讲, 审批的节点数量太多了, 其自身就是处于某种不良状态的病症。
你去开展一个BPM项目立项工作, 然而其出现的审批流程, 比你旨在要去进行优化的业务流程, 还要显得复杂许多, 难道说这算不上是一种黑色幽默情况吗? 这可不是吗?
那么, 当你提及BPM立项审批流程之际, 务必要将“审批流程”自身纳入优化范畴之中。如何予以优化呢? 需设定一个界限: 从原则层面而言, 核心决策层的审批节点不可超过3个。若超过3个, 等于是运用一把钝刀去切割牛肉, 耗费力气却难以收获良好效果, 事倍功半。
怎么让“关键先生”快速点头？
牢记着, 在审批流程当中, 始终存在着那么一两个人, 他们才是切实进行拍板决策的。这其中, 有可能是首席执行官, 有可能是分管副经理, 有可能是首席技术官。
针对这个人，你不能只给报告，你得给“预期”。
什么意思？
你要告诉他，上BPM之后，他每天能少签多少字，少开多少会，少听多少抱怨。
比如说吧, 你径直去写: “上线之后的情形下, 预计CEO每个月审批所耗费的时长会减少40个小时, 这也就意味着相当于额外多出5个完整的工作日能够用来进行战略决策了。”。
一经把数据摆放出来, 他的眼睛瞬间就明亮起来了。他所关注在意的向来压根不是系统, 而是他自身的那个时间。
立项前，必须想明白的致命问题
千万别为了上系统而上系统。
BPM项目立项的审批过程, 从根本上来说, 实际上是一次利益的重新分配行为。
原先靠着流程方面的腐败、凭借信息不对称来获取利益的那些人, 会对你恨之入骨。原先加班数量最多、流程最为杂乱、然而却最没有话语权的那个部门, 会对你满怀期待。
你推BPM，就是选择站在哪一边。
要是你并未思量清晰怎么应对那些“流程既得利益者”, 即便你的立项审批通过了, 往后也会被各式各样的软拒绝以及暗操作给整垮。
比如说, 存在一些人, 他们会刻意地拖延, 从而不去提供需求文档, 还有一些人, 则会声称“这个系统, 和我们所拥有的业务场景可不相匹配契合”, 并且, 另外还有一些人, 会在会议之上, 以阴阳怪气的口吻说“别折磨折腾大家了。”。
在你着手撰写BPM项目立项审批报告的这个时候, 这些事宜是需要提前做好预案的, 要将利益相关方分析涵盖进去, 并且把风险应对策略书写进去, 以此让老板能够看到, 你并非是一位单纯天真的技术员, 而是一位具备谋略的方案推动者。
别让“完美”害了你
太多人死在“准备万全”上。
等候着将全部需求都调研得清晰明白, 等候着把市面上所有产品都对比完毕, 等候着把预算精准到小数点后的两位数字。
等你搞完，黄花菜都凉了，竞争对手的BPM早就跑了一年了。
进行BPM项目立项审批时, 最为忌讳的便是“完美主义”, 你仅仅需要去证明这么一件事情, 即要是不上BPM, 那么成本将会远远大于上BPM所存在的风险。
哪怕你仅仅选购了唯一最为急切的痛点, 哪怕你所挑选的系统仅仅只有六十分, 只要它能够率先运转起来, 将那最为疼痛的环节予以打通, 后续的迭代便如同顺水行舟那般顺畅了。
牢记, 要先骑上马匹, 而后再配上马鞍。在审批流程当中, 老板最为惧怕的是什么呢? 是耗费了高昂的费用, 打造出一个所有人都不会去使用的“面子工程”。你去告知他, 我们采取分阶段的方式, 先花费少量资金进行验证, 倘若可行就予以推广, 要是不行就进行调整。这么一来, 他心里那块石头就落下一半了。
最后，关于那个“创始人海总”
我不知道你遇到的情况是不是跟我一样。
有的公司, BPM立项审批没办法通过, 并非是方案存在问题, 而是没找准关键的人。
要是你已然将所有能够去写的, 以及所有能够去做的, 全部都尝试过了, 然而依旧在某个特定节点处受阻, 真真切切地讲, 千万别一味地刻板坚持流程自身。
去问问“海总”这类真正懂业务痛点、有决策资源的引路人。
有时候，一个电话，比十份报告管用。
这世界从来不缺好方案，缺的是让方案落地的勇气和门路。
你的BPM立项，今天批了吗？
最新评论