立即开通体验×

只需10秒,即可快速申请开通体验

注册 登录
首页 > 协同观察 > 行业洞察

协同研究院

研究院简介

专家介绍

协同知识

协同期刊

体验产品

  • 大型企业协同管理平台 A8+
  • 中小型企业协同办公平台 A6+
  • 企业信创协同管理平台 A8-N
  • 移动协同办公平台 M3
  • 互联网+协同管理软件的发展趋势探讨
    时间:2018-02-28新闻来源:致远互联协同研究院浏览量:5063

    软件与互联网是一种怎样的关系,软件互联网化会是怎样一种体会?对于协同管理软件来说,是否存在互联网化的问题?本文试着对这一系列问题进行探讨。

    协同管理软件是基于B/S结构的,似乎可以看作就是一种互联网化的软件,而且由于协同管理软件是以人为中心,以流程制度的执行为主轴的面向全体人员的,解决人与人之间协作的管理软件。致远互联在协同管理软件诞生的第一天起就认为,协同管理软件消除信息孤岛、实现信息整合的应用类的系统级管理软件。

    细思却有些不同,互联网早期给我们提供的更多地是一种知识文档类的信息,而对于企业来说最多的也就是以展现企业状况、资源,推广企业产品和服务的名片式的网站而已,即使有所应用,更多地也只是一批在后台活跃的与call center一起协作的服务人员和网络营销人员而已。

    协同管理软件与ERP似乎并无很大的不同,是一种基于B/S技术的管理软件,但也许仅仅是技术而已。互联网所需要的开放、互联、平等、自由,对管理的影响的是去中心化、拆除管理的围墙、打掉管理的层级,但现实中似乎不是这样的,更多的业务系统各自为政,相互之间并不联通,组织管理似乎更加层级森严了,各部门的围墙似乎也是越累越高。也经常出现面对面走一个请假流程,不直接沟通而发一个协同以便“存档”后用的现象,很多的行政审批、报销流程、合同流程本来是三节点审批足以,但用了协同管理软件后变得很长很长……

    “互联网+”的真正趋势在于互联,这既有管理思想的含义,更是一种实现云计算、大数据、万物互联的技术机制。就技术机制来说,让软件成为互联网中的资源、数据,成为一种活的物种,提供对人、设备、软件自身这种物种可以利用的资源,应该是软件驻留互联网的本身含义。

    《数据结构》的沃思教授曾经定义软件是“数据结构+程序+文档”,其含义是软件是包括可运行的程序,程序运行所依赖的数据,以及使用说明书构成。在互联网环境下,软件运行程序与数据资源分离,使得软件能够单独提供计算能力给一组输入数据,并对输入数据进行加工、处理(期间也许包含人的干预或者互动),并输出数据信息结果,这就是计算的本义,也是图灵机理论的根本内涵。以协同管理软件举例来说,是否可以提供工作流给其他系统使用,是否开放“云计算”的一个示例,当然此处仅仅是举例而已。

    或者即使驻留于软件,也能够提供给其他系统使用,至少能够提供给同类的“软件物种”共享,或者分享出一些“软件计算的成果”,让软件系统之间互动、共享信息,并基于这些多种的信息资源的组合呈现给人使用,或者给其他软件系统使用,如果能够形成层级的架构组合,将可以通过蜂群效应形成更为复杂的庞大的系统。

    当然,这么复杂的系统如果通过人工进行配置,致远互联的DEE能够解决大部分的问题,但更进一步,我们能否实现软件之间的自动互联,或降低人类对于系统的干预呢?

    让软件之间能够自动互联,实现的不仅仅是文档的组合与连接,而是功能性的计算能力与数据组合,形成业务信息化解决方案,实现多业务、多种工作之间的自适应协作,这是终极的目标。协同系统的自动化还需要很多的支撑技术和理论模型。

    互联网上的信息一旦发布,将能够在网上永存,我们似乎已经很习以为常,甚至类似区块链技术被热炒,其本质是在互联网上分布存在的交易不能够被消除。

    软件分离出来是否可以成为在互联网中永远运行的系统----以一种可以感知的永续存在的“实体”而驻留于互联网中,是否就可以提供永续的服务,并且通过自我的迭代进化,通过多种终端随时提供给人类以服务呢?我想终极目标是终端的无关性,我们可以在任何设备上与互联网上的软件互动,获取信息资源、获取计算能力,并且能够获取组织的服务。

    这让我们看到,对于软件的互联网+,本质希望探讨的是一种架构,一种软件之间的生态构造。软件的迭代、进化不是人为的造作,而是软件本身对环境的适应,需要一种自我进化的能力,这就需要软件能过感知自己的存在,也能够感知周围互联网的环境,并且对自己的价值贡献比如被调用运行的次数,对外提供的信息有记录并能够评价。这似乎需要改变我们对软件模型的认知。

    如果软件永续运行成为一种真正的技术发展趋势,或者技术构造,那么软件之间互联将成为一种需要,软件之间协同工作就成为一种可能,这样互联网的软件的开发和发布模式也将发生改变。既然万物互联实质是指各种各样的设备、现实世界的各种变量比如车辆的速度(超速)、空气的指标接入,那么软件也可以成为一个“物”而被接入。而这对于客户需求和应用意味着怎样的改变,软件的可长期利用,软件的自我改进与进化似乎就可以堆叠开发斌进行“模块化”发布,而这正是目前电子商务软件类的saas系统的产品开发与发布已经实现的逻辑。

    协同管理软件似乎本身还不具有这样的特性和需求?

    除了ERP作为一种围绕资金、物料、票据为主的以财务为核心,以成本与收益为主题的所谓管理软件外,协同管理软件应该算是标准的管理软件了,因为协同管理软件是真正面向人的管理软件,是通过人与人之间的互动、通过流程、知识信息与制度协作而实现组织运作信息化的软件,是一种真正的以管理事件为信息化对象的软件系统。协同管理软件建立了正式的组织架构,展开了以人为中心的工作,成为互联网下的大规模全员应用的软件系统,更具有互联网的气质和特性。

    以人为本与以人为中心的争论,组织架构对于制度的影响?组织架构是否是组织生产要素的主要形式?如果是,是怎样一种结构、构造和体系,是否能够进行描述,从而改变管理软件的基础架构和特性,也许,这正是基于互联网可以做的改变!

    协同管理软件,至少致远互联的协同管理软件,确实依据组织架构构造了在互联网上的组织模型,并且实现了集团化的组织机构人员库,对于人在组织中的角色位置和层级地位进行定义,虽然还不够完善。

    然而,企业的老板并不希望本公司的协同中的流程制度、人员信息和知识系统全部暴露在互联网下,我们所期望的组织互联网边界的打破也因为组织本身的私利性而似乎不成立,然而就技术逻辑来说,协同管理软件应该驻留于企业内部,应该通过VPN进行适度保护从而利用互联网来作为通道传递信息,而不是将信息公诸于天下。其它软件之间的逻辑似乎也是这样,因为不同的软件服务的目的不同,使用的人群不同,所贡献的管理价值、业务价值或者客户价值不同,既有权力的问题,也有利益的问题,怎么可能像互联网的公开知识文档那样使用呢?又怎么可能像互联网上的开源软件那样不锁定使用权和拥有权呢?

    现有的协同管理软件设计就是为了解决这一些问题的,而不是为了能够互联的。因而协同管理软件从基础架构上就决定了必然是孤立的个体,独自服务于某一种管理目的,不能够从根本上实现互联,因为基础架构不支撑!

    软件之间是否需要协作?软件之间协作什么?当然需要协作,最基本的协作应该是围绕工作、业务的单据传递,如果涉及决策的话,应该提供决策的逻辑、程序、模型,以及相关的数据、信息甚或知识,而这些根本不是单一系统能够全部拥有的。

    而软件与人之间的关系,作为组织的管理软件,协同管理软件与组织之间的关系是什么?是不是可以通过协同管理软件构造“数字企业”,让企业本身成为协同管理软件,这样协同管理软件就成为了组织管理的基础平台,成为“组织”在互联网以空间中的独立存在!

    那么,协同管理软件能过提供什么?这些输出给了谁?是人、组织还是其他软件?其实都是,只是目前仅仅实现了人的连接,还没有实现与其他软件的连接,这里的实现机制包括人机界面的集成,我希望是门户,而这个门户本身是跨越“端”的,就软件系统来说,可以是M3,也可以是信息门户,这也是我们目前V7.0正在构造的伟大的梦想的基础部分。

    协同管理软件在计算能力输出上能够提供什么?协同管理软件在数据上能够提供什么?以什么形式提供?互联网+的第一步应该实现多套A8之间的互联,A8与G6之间的互联,让各套软件成多套软件协作的一个组件,从而构造出更为复杂的多软件的信息化系统,这样的信息化系统通过一种合适的架构,实现各套软件的自构造、自我进化,并实现集团化各企业之间的信息化互联互通,实现企业与政府的信息化互通。比如提交申请各类行政审批和政府的公共服务,集团企业之间的订单、物料、票据的自动连接,干部、人员的派驻,跨系统的动态问题解决团队的建立与工作的互动等等。 

    这是否就是未来的数字企业?数字企业是否可以与数字政府互动,比如报税,是否可以和其他商业机构互动,比如和银行自动获取资金往来并形成自动凭证,至少是原始凭证?

    低垂的果实在哪儿?如果不能够遭到低垂的果实,那代表着巨大的投入和不确定性的大幅度增加,这样的系统也许就只是幻想?

    协同管理软件发展趋势的灵活性、适应性的代价是大量的剩余,这些剩余提供了对不同行业、规模的客户的适应性,同时也使得系统变得臃肿、笨拙,客户支付的成本和使用的代价变高,系统配置变得不容易,使得交付成本、运维成本增加,而这些都需要软件架构上的考量。

    企业之间协作的依据在于契约,以及基于契约所规定的生产服务供给、产品供给和业务互动,并需要一些公知知识、共有信息作为支撑,这是跨单位协作的基础,此处以此举要提出一些更大的应用范围的问题,从而说明跨组织的企业协同比企业内部的协同更加复杂,还需要我们更大的努力去做探讨和研究。

    最后,需要说明,本文的探讨有些晦涩,这是因为理论架构和需求的宽泛适应性需要深度的探索与研究,而对于智能化或者说生物智慧,本文有意不予以讨论,以免带来更大的复杂性。

    相关推荐