|
日前某世界著名500强公司的CIO吐槽：业务部门非要绕开it部门，独立开发it系统，因为业务部门嫌弃it部门的工程师太笨，听不懂业务部门的需求！总是会错业务部门的意！ 再有，it部门的工程师工作流程太笨重了！效率太低！申请it部门的支持流程太漫长！ 如果业务部门非要踢开it部门，独自建立it系统，作为公司的cio到底应该如何应对呢？是完全拒绝，Or半支持半拒绝，Or完全支持？ 这里也给大家引入一个概念：shadow IT shadow IT ——常常用来描述不在it部门直接参与下，甚至在it部门完全不知情的情况下，由业务部门自主开发的信息系统或是数据保存与传输方案，根据权威调查，影子项目通常占据it系统的比例：
以下我们分析下影子项目(shadown IT)存在的合理性： 第一、业务部门和IT部门分别作为信息的发送方和接收方产生了沟通障碍，信息在传导过程中失真扭曲。 在业务部门看来，信息源被IT部门过度加工，同时存在理解偏差，最终造成需求扭曲；在IT部门看来，业务部门信息源目的不明、叙述模糊，没有清晰的表达信息的内涵，这个黑锅我不背；于是，最终形成双方扯皮。 第二，业务部门需求太紧迫，不允许层层申请，等待it部门开会研究，再研究，于是业务部门不得已，委托第三方来开发了。 这种情况是存在的，因为业务部门有钱，内部也会把钱分给it部门的，如果it部门承接开发任务的话。 第三，业务部门与it部门在成本估算上，不对称，业务部门一怒之下，抛弃it部门，另找外部资源支持，甚至在业务部门内部单独成立开发小组，满足特定项目的开发需要。 这也是可能存在的，尤其是集团各个分公司之间的相互支持，是需要核算成本的，如果it部门与业务部门对人工成本，开发周期达不到一致意见的话，可能it部门会拒绝，或者业务部门会拒绝。 最后，软件生产方式已经呈现出多元化发展的势头，由行业专家或者高级业务顾问主导的软件设计方式，已经可以取代传统软件开发方式中IT人员主导、业务顾问参与的开发方式。 目前，信息技术发展日新月异，随着行业最新Yigo人工智能自动化软件工程技术的广泛应用，软件生产方式已经呈现出多元化发展的势头。由行业专家或者高级业务顾问主导的软件设计方式，已经可以取代传统软件开发方式中，由IT人员主导、业务顾问参与的开发方式。 简单来说，就是通过Yigo自动化软件开发，业务专家可以不考虑技术，完全从业务视角出发，进行产品或项目的业务蓝图设计、界面元素布局及数据关系界定，最终自动生成业务应用系统。 传统开发方式由于业务架构、需求扭曲、原型设计上考虑稍有不周或存在缺陷，就会产生代码重写的返工成本甚至于推倒重来，从而导致项目的开发失败。然而利用Yigo设计，即使有业务架构设计缺陷，也仅需要对原型文件进行修改，不会涉及到代码重写的过程。 另外，小编谈谈影子项目的好处，不同意的小伙伴，可以加入论战！ 首先，可以刺激业务创新，业务部门是离需求最近的部门，如果按照业务部门主导的思路，那么软件系统的功能至少不会偏离需求，甚至会为需求的实现逻辑找到完美的方案。 其次，快速实现需求，快速提供与需求相对应的it系统，推动业务部门业绩增长。 第三，降低项目成本，可以缩短项目周期，降低沟通成本，节约人力工时，最终达到降低项目总成本的目的。 这很好理解，比如一个app，用户体验不好，如果能够很快得到提升，就可以很好的改善用户体验，刺激app快速得到传播，反之可能持续降低客户体验，口碑不好的app是很难翻身的！ 以最涨姿势的角度，九浅一深地感知企业信息化的喜怒哀乐 |
|
|
