来源丨智能制造那点事
全文共5486个字,建议阅读 10 分钟
规模小,一般2~3人,负责与管理层、各业务部门对接,整合和落实管理层业务战略愿景,并推动具体业务部门和IT执行落地;
规模中,一般7~8人,包含各具体业务领域知识的专家,如懂供应链、工艺开发、生产运营、设备标准、前沿先进技术、质量管理细分领域的;
规模稍大,人数10人以上,除包含规模中的能力外,还包含部分数据研究分析能力,能够针对特定场景的核心过程数据,能够进行分析,并总结、提炼,配合供应商进行模型研究。
整体规划能够让管理层看到未来2~3年的整体蓝图,更容易界定这个标的是不是与他对企业或者战略发展方向的定位是相吻合的,管理层的认同对于后续下面执行层的推动是非常有利的,行业有一种说法叫“所谓领导重视的项目一般都比较好推”;
有了清晰的整体规划,更好识别促成整体规划可落地的相关资源要素的匹配,如预算、人才等;
整体规划也是对企业现状的一种最好的摸底,虽然说规划要仰望星空、对标一流,但我们不能忽视规划最最重要的属性,即立足于企业当下和实际。通过整体规划的行动,识别出企业当下面临的困难和业务痛点,有时候我们会说,整体规划也是一种持续改善;
如果没有整体规划,很容易被乙方的顾问给”带偏了“。乙方一般的策略是买解决方案附带卖产品,站在乙方的视角,我也非常能理解,他们需要尽可能把自家的产品卖给客户,卖的越好,业绩就会越好。很少有乙方在讲解决方案的时候,对用户的现状进行全局分析的,如甲方已经有什么,哪些地方做的好,哪些地方做的不好,我的解决方案是否真的能够给甲方带来价值提升,我卖的解决方案对甲方来说是must,还是nice to have?细心的小伙伴可能会发现,很多顾问在甲方讲解决方案的时候,都是一个劲的在讲,我有什么,我有什么,估计有90%的时间都在讲我有什么,很少有顾问愿意用50%的时间来分析你需要什么,然后再用50%的时间来讲我有什么。
业务架构更多体现业务管理层对于部门业务中长期的发展战略定位和业务部门运作流程,业务比IT更了解业务,更重要的一点,相比IT,业务规划团队有独特的优势,他们有更多的机会和管理层进一起开会、访谈交流,他们更懂管理层的心声;
技术架构更偏向底层技术,IT会比业务更懂,知道如何进行资源部署配置,实现性能最优,如使用5G还是wifi,部署私有云还是公有云等;
IT要和业务保持密切的协作,构建管理Council机制,IT人员前期可以参与业务架构规划的讨论和交流中,从技术层面,给业务人员提供技术指导,便于业务架构最终可实施的可能性。
业务和IT深度融合的过程中,有一点稍微提一下,可能有些企业在推这种模式中面临的问题,功劳属于谁。业务和IT的深度融合,要求双方团队都要保持开放、包容的心态,因为这种合作模式和传统的业务只提需求,IT全权负责的模式可能有些不同,这种模式前期业务主导,后期IT主导,所以关于谁的功劳更大,其实这个问题本身也不是问题,毕竟IT汇报给IT线,业务汇报给业务线,本身也不是一条线汇报,IT不必和业务计较,业务也不必和IT计较,各有各的绩效考核管理线。项目做的好,双方都可以得到褒奖。
偏向工业知识know how多的,这类的软件都比较适合Buy,如PLM、仿真软件、SAP、MES等,如果选择自主开发,一方面周期长,另一方面,这些系统的底层数据模型非常复杂,没有对业务非常精通的架构师,开发出来的系统,后期对业务可持续拓展的能力是非常薄弱的;
传统工业软件的轻量化适合Make,比方说PLM软件的很多loading、UI界面、各种用户交付的data reports等,SAP系统的生产计划和MRP,我个人觉得这些国外的工业软件最大的优势是底层的data model的规划,最大的缺点是笨重,开发了很多用户不需要的功能,显得非常笨重,用户体验不好,随着带来的问题就是性能蛮。
面向终端用户2C的,如果甲方IT开发能力比较强,可以选择Make,因为这块业务是最能彰显企业对于用户体验和个性化需求的追求;
面向企业运营管理的,一般建议Make,一方面这些数据量不是特别多,而且数据基本都较为保密,另外一方面,这些数据往往都来源于上下游各个应用系统,甲方主导来协调各方面资源、推动起来会比乙方更容易一些,运营数据管理本身也没有特别大的技术难度。
耗费周期长,因为固定总价,所以潜在甲乙双方在准备SOW的时候,字字斟酌,乙方担心前期若范围不谈清楚,后期范围的变更承受不了;
灵活性差,偏管理类的信息化项目,即使前期规划的很多,但是在具体实施过程中,还是会存在很多需求的变更和调整,针对fixed price的合同,后期的每次需求变更都需要反复和乙方扯皮;
不可持续,fixed price合同一般都有固定的项目结束周期,项目上线交付后,乙方通过验收,基本就撤离了,交给甲方来运营管理,很多企业的甲方一方面可能没有能力、另外一方面可能也不是很重视运营,导致很多上线的项目和系统,半年后,就黄了,很少有人用。
甲方要真正能朝着这个合作模式走,有个必要的条件要满足:
甲方内部有这方面有规划能力、综合项目管理能力的人;
甲方可以和相关潜在合作供应商签署战略人天合作框架协议;
乙方也愿意配合甲方这种人天合作模式。
很多软件不是为企业的业务量身定做的,项目实施过程期间,真正的用户往往参与的时间很短,一般就需求调研阶段和用户接受测试UAT(User Acceptance Test)阶段,加起来估计也不足半个月,而且好多业务关键用户在这个参与其间,又不是全职,还有很多本职的工作,所以在这个阶段,想让最终使用的用户能对系统功能和体验做出很恰当判定是不可能的;
项目功能测试的数据也是伪造的,UAT测试不可能把所有的业务流程都能按照1:1实物流程运作一遍,这个时候的测试往往并不能识别很多潜在的问题;
业务的需求在不断的变化,很多业务本身也是在不断通过项目不断优化和完善,因此不可能基于半年前或者一年前提的需求,还能那么好的兼容;
软件系统的笨重和复杂,若没有足够的运营支持和不断的培训推广,很多用户就放弃使用了。
系统IT系统运维策略,保证系统的运行稳定性、可靠性和性能; 制定业务数据运营,针对系统内的业务数据质量和流程,根据实际用户的使用情况,定期分析和评估判定,识别出影响系统应用的潜在问题和风险,并和规划团队进行沟通,制定改善策略; 制定系统用户推广机制,包含培训、日常问题对接处理响应机制。
08 不忘前沿技术的研究储备
参观对标交流,通过学习别人的案例,了解前沿技术的储备和应用情况,这个也是最简单、最直接、最可行的方式,通过看和听来了解;
尝试和一些具有代表性的企业展开一些合作研究,比方说AI算法如何应用于工艺过程质量预防;
经济条件允许的企业,可以内部设置一些先进技术研究实验室,可以联合高校、生态圈其他同行建立联合创新项目,真正落实产学研一体化融合,让高等学府的孩子们能够尽早了解企业的需求。
-- End --
3、
4、
9、
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...