集成底座项目实施规程

Posted 数通畅联

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了集成底座项目实施规程相关的知识,希望对你有一定的参考价值。

对于绝大多数企业来说,企业的信息化建设是随着企业业务的发展不断推进的,而随着企业业务的复杂化和多元化,对于信息化系统的要求也越来越高,对于信息化建设的整体架构、集成整合、数据治理、安全管控的要求也在不断提升,而集成底座就是从企业信息化建设的角度出发,搭建统一、标准、柔性、可复用、可扩展的IT架构,解决企业信息化建设过程中缺乏整体规划、集成整合难度大、安全管控不到位等问题。

集成底座主要包括IDM统一认证平台、MDM基础数据平台、ESB企业服务总线三个产品,产品之间相互支撑,同时对外提供数据和服务。对于企业而言,集成底座更多的是提供一套系统解决方案,奠定企业IT基础,所以在实施集成底座项目时,要立足长远,要充分考虑企业未来的信息化发展趋势。

1总体说明

集成底座主要包括三个产品:IDM统一认证平台、MDM基础数据平台、ESB企业服务总线,其中IDM平台基于5A管控体系实现统一用户、统一认证、统一授权、统一审计、统一应用管控等安全管控;MDM通过支持组织、岗位、人员等主数据的同步分发,实现主数据的标准化,实现全生命周期的主数据管理;ESB作为集成通道,通过API管理将业务系统接口注册、代理到ESB平台,并通过平台实现集中监控、认证、限流、报警等功能,在满足IDM、MDM以及上下游系统的集成管理的同时实现服务接口的集中化管理。

1.1集成架构

集成底座方案的集成主要是基于IDM和MDM作为数据的集中维护平台,通过ESB进行服务API的管理,构建集成通道,从而实现IDM、MDM以及上下游系统的打通。由业务系统作为基础数据的源头,这些基础数据通过ESB同步至MDM平台进行统一管理,保证基础数据的准确性、唯一性、完整性;MDM将组织、人员等基础数据分发至IDM生成对应认证账号信息,用于支持统一认证等业务;整个集成过程中,ESB作为服务总线负责对各个系统的接口和服务进行注册和管理,同时构建系统数据对接的集成流程。 

1.2业务场景 

集成的业务场景集成主要是基于IDM和MDM的数据同步分发,其中包括业务系统到MDM的主数据同步,主数据到下游系统的下发(包括下发IDM),以及IDM下发账号到下游系统等。 

1.主数据同步: 

1)源头推送数据(或者推送查询标识)至ESB的集成流程; 

2)ESB集成获取源头数据(或者通过查询标识从源头查询数据)后,在集成流程内部调用MDM的接口,将数据写入MDM,同时生成任务和日志,并回写源头系统; 

3)ESB集成流程调用MDM的自动提交接口将任务提交至MDM的BPM工作流中,BPM工作流调用MDM接口实现数据向下游系统的分发。 

2.主数据分发: 

1)主数据分发采用推送的方式,在MDM的BPM工作流中触发推送; 

2)下游系统需要提供数据接收接口,在MDM中配置该接口,并在MDM的BPM工作流中调用MDM的分发接口(分发接口内部调用下游系统接收接口)实现数据分发; 

3)下游系统接收数据后,接口内部进行系统写入,完成后调用MDM的日志回写接口进行数据回写操作。 

3.账号分发: 

1)账号分发主要是通过IDM将登录用户信息分发至下游系统,实现各系统的统一认证和单点登录; 

2)IDM账号分发主要是将IDM的账号信息通过任务的形式分发下游系统,和MDM的分发方式类似; 

3)在账号信息进入IDM平台,可以手动或自动的方式生成分发任务,再通过IDM内置的BPM工作流进行自动提交; 

4)在BPM工作流内调用IDM的分发接口将数据推送至下游系统的数据接收接口中,而下游系统的数据接收接口则配置在IDM平台的应用管理中; 

5)下游系统完成数据写入后调用IDM的日志回写接口进行数据回写操作。 

1.3实施模式 

集成底座主要包括IDM、MDM和ESB三款核心产品,通过反复的内部演练以及实际项目的磨练,目前集成底座已经逐渐形成了一套标准的实施规范,包括主数据的规划、数据同步分发、账号管理、统一认证、API管理等,所以目前集成底座更多采用产品 + 培训的交付模式,即我们提供产品以及基于云平台的环境部署、产品安装,同时提供对于各个产品、集成方案、接口开发的培训,由伙伴或者客户方来完成具体的实施和建设工作,而在实施过程中,我们进行远程或现场的技术支持和指导。 

集成底座的实施模式需要轻实施、重培训,强调伙伴或客户在实施过程中的参与,这样做的好处在于: 

1.降低项目参与度,减轻工作量,能将项目团队投入到更多的项目中,满足公司发展需要; 

2.内部团队有更多的机会参与项目、了解业务,了解产品和方案在实际项目中的应用,有利于团队的建设和成员能力的培养; 

3.培训伙伴或客户熟悉产品的使用和项目实施,发挥伙伴方、客户方的优势,加快项目实施交付的效率; 

4.伙伴或客户掌握到产品和方案的精髓后,更有意愿去推动更多的同类项目,从而提供更多的商机,提高产品出货量。 

1.4实施流程 

集成底座项目的实施流程也是遵循规范的项目实施流程,包括需求调研、环境部署、实施交付、上线验收、后期运维等阶段,但是和实施类项目不同,集成底座采用产品 + 培训的模式,所以更多的工作是需要交付伙伴或客户方完成的,项目团队更多的是起到辅助的作用。 

1.需求调研由项目团队和实施方共同完成,项目团队提供调研模板、调研大纲、调研思路,双方共同参与明确项目需求和范围,实施方了解业务、需求,同时熟悉产品的使用,便于后续的实施交付;项目团队提供资料协助实施方完成调研,同时搭建测试环境,培训实施方了解产品的使用,同时项目团队需要在调研过程中了解客户的业务,强化业务能力,也为后续项目提供借鉴; 

2.环境部署:环境部署一般由项目团队或内部运维团队负责,集成底座采用云平台的部署方案,提供一键部署脚本和对应的文档,可以实现快速部署;在实际项目中一般会部署两套环境:一套测试环境采用非高可用部署,在前期调研阶段部署,用于给客户演示、调研需求和产品使用培训;一套生产环境,一般在正式实施时部署,采用高可用部署,搭建开发、测试、生产环境,满足后续项目开发、测试、生产运行需要; 

3.实施交付:集成底座主要采用产品 + 培训的实施模式,实施交付的主体一般是合作伙伴或客户的信息化团队,项目团队主要是根据前期调研的需求协助输出对应的标准规范、蓝图资料,以及在实施过程中提供产品培训、技术指导、方案支持等,一般提供远程支持,但可以根据实际情况,提供短期的现场支持; 

4.上线验收:上线、验收和实施一样,主体也是合作伙伴或客户的信息化团队,项目团队以支持、辅助为主,协助实施方输出上线文档、上线流程、回滚策略等,协助实施方完成项目的整体上线试运行,以及最终的项目验收; 

5.后期运维:一般运维工作内部会移交运维团队,具体运维工作由伙伴或客户方进行,内部运维团队只负责解决一些产品使用、功能上的问题,同时针对伙伴或客户方经常出现的问题进行技术指导和培训,协助伙伴或客户更加深入地掌握产品和方案,以促进后续更多的合作。 

对于集成底座项目,在实施交付过程中,在不同的时间节点,需要交付的文档清单如下: 

  

  

2需求调研 

需求调研是项目实施的第一项工作,也是非常重要的工作,由于前期项目团队、伙伴、客户、业务厂商的熟悉程度不够,缺乏足够的信任,往往需要一段时间的磨合,所以在这个阶段需要经常沟通、相互交流、加强合作、达成共识,为项目的成功奠定基础。 

集成底座项目又是一个跨组织、跨业务、跨系统的项目,所以调研时往往需要对客户的需求、实际的业务、系统的情况、厂商的配合等各个层面进行调研,更需要项目团队掌握沟通技巧、了解产品方案、熟练调研流程。在沟通过程中,需要不断输出集成底座的实施方案,引导客户、厂商按照集成底座的标准模式进行实施,降低实施交付的难度,以达到项目的快速交付。 

2.1主数据管理 

主数据的调研一般需要从项目的整体规划和实际业务出发,梳理主数据的具体范围,以及每一类主数据的编码、属性、来源、目标、集成等内容,具体内容可以包括: 

1.项目规划:项目规划一般在客户进行项目立项时就会明确,规划具体的建设内容和建设范围,但是在项目开始实施时,实施团队需要和客户反复进行讨论,一方面是对具体实施范围进行确定,确定哪些做,哪些不做;二是对客户进行引导,使项目的实施过程遵循集成底座的标准流程,便于后期实施交付和上线验收的推进; 

2.核心业务:调研过程中要充分了解客户的核心业务,梳理业务时结合现有的业务系统进行分析,明确业务运行过程中可能涉及的主数据,同时在梳理过程中也要对客户的业务进行分析整理,积累对业务的认知和理解,为后续项目的实施、售前、产品开发等提供借鉴; 

3.类别明确:明确本期项目需要建设的主数据类别,如果单纯从集成底座的角度,一般只需要建设组织、岗位、人员等人事相关基础数据,但是为了满足客户的业务需要,同时加强集成底座的实际应用场景,可以考虑根据实际业务建设一些重要的主数据,支撑业务的同时也为后续深度主数据治理和数据中台建设奠定基础; 

4.编码规则:主数据的编码规则一般有两种情况:一是由源头系统提供,MDM平台直接引用源头系统编码,二是在MDM平台配置编码规则,在数据同步到MDM平台时自动生成。第一种直接复用源头系统,MDM无需进行处理,但是需要源头系统保证编码规则的唯一性、准确性;第二种MDM需要配置编码规则,可以保证唯一性、准确性,但是在同步时需要将编码回写源头系统,二者各有优势,在实际项目中可以根据实际需要灵活选择; 

5.属性定义:MDM支持元数据管理,可以根据实际需要配置各类主数据的属性信息,一般属性的定义需要包括以下内容:源头系统包括的属性,并且需要分发到下游系统,实现多系统共享;在实际业务运转过程中需要维护使用的属性; 

6.参考数据参考数据由业务系统提供,一般由源头系统提供,MDM平台参考进行配置,同时由于各个系统参考数据的定义是不同的,所以涉及数据下发时,需要明确下游系统的参考数据定义方式,并在MDM平台进行关联配置; 

7.校验规则:主要是针对不同的属性配置校验方式,如非空、数字、唯一、长度等,主要是为了保证主数据的规范性、完整性,降低人工维护时产生的异常数据; 

8.来源系统:针对每一类主数据需要明确主数据的权威来源,来源于哪个系统的哪个模块,是否能采用推、拉的方式进行数据推送,是否可以配合进行扩展等; 

9.目标系统:针对不同的主数据需要明确都有哪些业务系统进行接收,是否有对应的接收接口,是否能够配合进行扩展,接收时需要接收哪些元数据等; 

10.集成方式:集成底座的数据集成支持推、拉、定时等方式,但是为了保证数据的及时性,绝大多数采用推、拉的方式,一般会涉及上下游系统的改造,包括上游系统的实时推送,以及下游系统的数据接收接口等,在调研时要明确具体的集成方式以及相关数据接口。 

2.2.统一认证 

统一认证主要是基于集成底座的IDM平台实现的,平台提供了CAS、OAuth、接口三种认证方式,满足不同场景、不同系统的对接需求。在前期调研过程中,要明确需要对接统一认证的系统有哪些,分别采用哪种开发语言、技术架构,针对不同的语言、架构提供认证方式,具体实施时由系统方根据认证标准自行配置处理。 

IDM平台支持密码集成,包括密码同步、密码分发,但是在实际项目中,不建议进行密码集成,一方面进行密码传输的过程中,容易造成密码泄露,增大安全风险;另一方面实现统一认证之后,登录直接采用统一认证,使用IDM的密码进行认证,不需要保持业务系统和IDM的密码一致。 

2.3统一API 

集成底座的统一API主要是基于ESB的API管理功能实现,在ESB的SMC管理控制台中将各个业务系统的接口统一注册进来,支持Web、Rest、Http等不同类型的服务接口,注册后的接口可以在应用集成中调用,也能通过代理的方式提供给其他系统。 

在项目调研过程中,主要需要明确接入的业务系统有哪些,除了集成底座内部的接口注册以及应用集成配置外,是否有其他系统需要进行接口注册,是否有单据集成、凭证集成等集成需求,是否需要在ESB进行接口统一管理。 

对于注册在ESB中的接口,需要明确对于接口安全、数据安全、数据加密、安全认证、异常报警等机制的需求,根据需要进行标准制定,以便后续实施过程中进行对接。 

2.4标准规范 

集成底座的标准规范主要包括以下内容: 

1.主数据数据规范:根据制定的主数据范围,制定每类主数据的相关数据标准,包括编码、属性、参考数据等; 

2.主数据管理规范:从组织管理角度出发,针对主数据的管理组织、管理角色、管理人员、维护流程等内容制定统一的标准要求; 

3.主数据集成规范:基于制定的主数据范围、属性,以及对接的上下游系统,制定数据集成标准,包括推送、拉取的方式,触发的机制,推送的内容和业务系统等; 

4.主数据清洗规范:主要针对MDM平台的数据初始化,对于现在系统中已有的历史数据,在初始化同步到主数据平台时,如何进行清洗、合并、标准化处理; 

对于主数据的数据规范、管理规范、集成规范、清洗规范,一般会合并到同一个主数据标准规范文档中。 

5.MDM主数据平台接口说明:MDM平台的接口标准文档,该文档会根据MDM平台的开发和升级进行升级。 

6.IDM身份管理平台接口说明:IDM平台的接口标准文档,该文档会根据IDM平台的开发和升级进行升级。 

7.ESB企业服务总线服务标准:ESB平台的标准说明文档,主要针对ESB平台服务接口的开发标准、协议支持等。 

8.IDM统一认证对接标准:主要针对IDM统一认证相关的内容说明,包括统一用户说明,CAS、OAuth、接口认证说明,以及统一密码实现说明等,参考如下。 

3环境部署 

集成底座采用云平台的部署方式,在实际项目中一般由内部实施团队或内部运维团队负责部署安装,一般会建议部署两套环境,一套是基于3台服务器的非高可用环境,一般用于前期调研时对客户进行产品演示、样例说明,以及针对伙伴或客户信息化团队的培训工作;另一套环境是在调研后期或蓝图确认后部署的正式环境,采用至少5台服务器的高可用环境,内部至少部署开发、测试、生产三个环境,以保证在实施过程中的可以进行产品的配置、环境的搭建。 

3.1K8S部署 

集成底座采用云平台部署方案,现在K8S的云平台部署已经构建了一键部署脚本,可以通过脚本实现快速部署,同时支持离线部署,即使在内网环境下,也可以完成环境部署工作。并且针对3台非高可用和5台高可用提供不同的部署脚本,可以满足不同使用场景的需要。 

3.2产品部署 

集成底座除了包括IDM、MDM、ESB三款核心产品外,还有UMC云管理平台,主要用于配置和管理K8S集群,以及集群内部的环境、容器、产品、组件等配置与部署,以及外部nginx的接入配置等。对于UMC上容器、产品的部署,也支持通过一键部署脚本进行操作,并提供由对应的部署文档。 

3.3 安全策略

集成底座一般面对企业级客户,并且涉及了企业的核心数据,为了保证数据的安全性,需要从网络、服务器、产品等多个层面保证系统的安全性,主要包括: 

1.在准备服务器时建议搭建堡垒机,通过堡垒机跳转访问真实服务器,提高服务器安全性; 

2.服务器防火墙只开放内部服务器之间的IP互通,不开放外部IP和端口的访问,对于部署外部Nginx的服务器,根据部署的环境对应开放相应的端口; 

3.对于Redis、数据库、产品等相关密码都需要采用复杂密码,并且保证密码是不一样的,避免密码泄露的可能。 

3.4环境测试 

环境部署后需要对环境进行整体测试,包括产品功能、服务接口、集成流程,要根据实际业务需求对功能、压力进行测试,保证功能可用的同时,也要保证服务器的稳定性和并发压力。主要测试内容: 

1.IDM、MDM、ESB的各个功能模块,包括页面显示、数据管理、配置功能等,以及ESB设计器的连接,工程、服务、流程的开发部署等; 

2.IDM、MDM、ESB的相关服务接口,包括数据提供、数据接收、任务处理、token认证等; 

3.IDM认证压力测试:对IDM的CAS、OAuth、接口认证进行压力测试,基于JMeter模拟实际业务场景进行并发压力和稳定性测试,主要测试高并发的认证登录以及低并发长时间的稳定性(8-10小时); 

4.MDM数据接口测试:针对主数据的同步、分发、查询接口进行压力测试,主要测试低并发、大数据量的情况; 

5.测试后需要输出对应的测试报告。 

4实施交付 

集成底座采用产品 + 培训的实施模式,项目的实施交付主体为伙伴或客户信息化团队,而内部项目团队主要负责产品培训和技术支持,以远程支持为主,根据具体项目进度和实际情况,可以短期进行现场技术支持,但实施的主体也是伙伴方,而非项目团队。 

对于集成底座项目,主要的实施内容包括: 

1.数据集成:以主数据为主,进行MDM和上下游系统之间的主数据同步分发,其中包括了IDM的数据同步,以及IDM用户数据的分发; 

2.应用集成:以IDM为主,实现各个系统的统一认证,搭建统一认证中心; 

3.服务集成:以ESB为主,将各个系统的服务接口注册到ESB平台进行统一管理。 

4.1产品培训 

产品培训是集成底座项目中非常重要的部分,由于采用的产品 + 培训的模式,所以需要通过培训让实施方充分了解产品的特性、使用场景,以及对于不同的业务场景,应该如何通过产品配置进行实现。培训的主要内容需要包括: 

1.集成底座的整体集成架构、数据架构、集成方式等; 

2.集成底座和上下游系统集成时,集成的内容、集成的方式,提供的数据; 

3.MDM平台数据管理维护的方式,主数据模型的配置过程,包括模型定义、属性定义、编码规则、校验规则,以及同步分发过程中的系统注册、分发范围、接口调用等; 

4.IDM平台组织、岗位、用户的管理维护方式,扩展字段的配置,密码策略的配置,统一认证的配置,同步分发的相关接口说明等。 

4.2数据集成 

主要是主数据的同步分发,包括: 

1.从源头系统主数据同步MDM平台; 

2.MDM平台数据下发下游业务系统; 

3.MDM平台组织、岗位、人员数据下发IDM; 

4.IDM用户数据下发需要接入统一认证的系统,保证账号一致。 

数据集成的过程中,需要主推标准的集成方案,集成底座内部的数据集成可以直接复用预置的相关服务样例,和上下游系统对接时直接根据蓝图阶段制定的标准规范。推荐实施方式: 

1.主数据同步采用推送模式,由源头系统触发推送数据,通过ESB开发应用集成流程实现源头系统到MDM平台的数据写入; 

2.MDM平台下发由下游系统提供接收接口,集成底座提供标准的数据格式,采用MDM的推送(或推拉)模式将数据(或任务标识)发送给下游系统; 

3.IDM的账号下发和MDM一样,也是由下游系统提供接收接口,IDM采用推送(或推拉)模式将数据(或任务标识)发送给下游系统。 

4.3应用集成 

应用集成主要是基于IDM平台构建统一认证体系,打通系统访问的壁垒,IDM平台提供CAS、OAuth、接口认证三种认证方式,业务系统根据自身系统情况自行选择,实施团队协助提供配置样例和说明文档。 

一般集成底座的IDM实施会以统一用户、统一认证、统一审计、统一应用管控这4A为主,而统一应用管控是在IDM平台配置各个系统信息,统一审计是对数据的统计、分析和监控,所以统一用户、统一认证往往是集成底座项目中最多的内容。 

1.统一用户:IDM用户分发下游系统,保证IDM和下游系统登录账号的一致性,建议采用推送模式,IDM提供标准的参数格式,下游系统提供数据接收接口,由IDM平台推送用户数据至下游系统; 

2.统一认证:基于IDM的标准认证方式,以下游系统为主配置统一认证。 

4.4服务集成 

以ESB的API管理为主,对业务系统的服务接口进行API注册、API管理、API代理、安全策略、监控预警等内容。 

1.配置ESB应用集成时进行服务接口的引用; 

2.其他系统集成时调用ESB代理接口,通过ESB进行日志记录、监控、预警等; 

3.推荐对接的接口都注册到ESB中,基于ESB进行监听和管控; 

4.对于IDM、MDM、ESB等内部使用的接口,全部注册到ESB中通过应用集成调用;如果支持外部系统调用,则需要对接口进行代理; 

5.如果项目中存在单据集成、凭证集成的业务集成需求,则需要通过ESB进行API的注册、代理,业务系统直接调用代理接口; 

6.如果需要保证数据安全性,建议采用数据加密、token认证等机制进行接口控制。 

5上线验收 

上线验收和实施交付一样,也是以伙伴方的实施团队为主进行推动,内部项目团队在这过程中进行辅助支持,以保证项目的顺利上线,包括上线前期的资料准备,风险评估,以及上线后的运行监控、产品问题修复等。 

5.1上线准备 

在上线前需要对上线需要做的工作提前进行梳理,形成上线文档,明确上线时间、上线步骤、初始化数据、接口切换等内容,由于集成底座项目涉及各个系统的集成与切换,所以需要和客户方提前约定时间,在不影响客户业务运行的情况下进行升级切换,特别是存在历史系统的升级的情况。 

1.上线时间:上线的开始、结束时间,数据准备、系统切换的时间节点,需要明确到具体时间点; 

2.上线步骤:上线的具体流程,包括数据服务器准备、环境部署、数据初始化准备、系统切换、接口切换等,并且需要明确每个节点的人员和时间节点; 

3.初始化数据:包括IDM、MDM的数据初始化以及业务系统的数据初始化,明确数据初始化的时间节点和负责人; 

4.接口切换:原有系统的接口切换步骤,包括旧接口的停用以及新接口的启用时间节点等。 

5.2风险预案 

风险预案主要是针对上线过程中可能出现的问题进行提前预估,并制定解决策略,如果上线过程中出现问题,可以按照风险预案进行紧急补救。一般情况下由于集成底座采用云平台部署,可以直接通过资源同步快速部署生产环境,同时在上线前也会在测试环境进行模拟验证,所以大多数情况下上线会比较顺利。 

但是由于集成底座会和各个业务系统集成,所以可能出现业务系统交互异常的情况,所以针对各种可能出现的问题要提前进行预估,如上线后无法实现统一认证拦截,统一认证成功后无法跳转业务系统,数据集成时出现数据同步失败,ESB代理的API无法调用等问题,针对每一个可能的问题都需要制定问题排查处理的策略,保证可以快速进行问题定位和处理。同时也需要做好最坏的准备,即上线回滚,如果问题比较严重,上线后无法满足业务使用,则需要制定回滚策略,回滚到上线前的状态。 

5.3 上线监控

在项目上线后需要实施团队实时关注项目运行情况,包括IDM认证情况、MDM/IDM的数据同步分发情况,ESB服务接口的调用情况,同时也需要对服务器的运行情况进行监控,保证各个产品可以稳定运行。 

上线监控阶段不仅需要实施团队进行监控,客户方的信息部门以及业务人员也要参与其中,主要是确认业务运行是否顺利,是否存在数据异常等问题,并且对过程中的问题进行记录和反馈,实施团队及时跟进处理,保证项目的顺利上线,以便于推动后续的验收。 

5.4验收推进 

在上线运行稳定之后,实施团队需要开始整理项目验收资料推动项目验收,根据项目的具体情况,验收资料也会有所区别,对于集成底座项目,一般至少要包括以下内容: 

1.服务器信息,环境部署清单,部署文档和资料,相关登录账号和密码; 

2.需求说明书、设计说明书、使用手册、操作手册、标准规范、集成说明等蓝图资料; 

3.产品测试报告、安全报告等测试相关资料; 

4.项目运维文档、常见问题处理等运维相关资料。 

项目的验收推送也是以实施方为主,内部项目团队主要是提供相关资料模板和说明,协助实施方出具相关验收资料。 

6后期运维 

后期运维主要包括两部分内容:一是由伙伴的实施/运维团队进行的日常运维,一是由内部运维团队进行的远程技术支持,主要处理实际业务中出现的产品级问题。 

6.1运维团队 

由于集成底座采用产品 + 培训的方式,所以运维会以伙伴方为主,伙伴方根据实际情况建立运维团队进行日常的维护,协助客户进行问题定位与处理,主要处理客户实际业务中出现的使用问题、相关流程的优化、配置的优化等,以及客户业务变更时出现的流程调整等内容。 

内部运维团队主要负责解决产品级问题,如果产品在实际运行过程中,如果出现产品BUG,内部运维团队需要协助进行问题定位与处理,同时对于产品在使用过程中也要对伙伴和客户进行指导,加强使用方对产品的深度理解。同时为了保证集成底座的应用效果,一般在项目上线后也会进行一些产品升级,这些升级工作需要内部运维团队提供升级说明,协助伙伴方完成升级。 

6.2运维流程 

针对项目中运维工作,需要制定标准的运维规范和流程,包括客户使用产品的方式,使用过程中的注意事项,出现问题时反馈的渠道、反馈的方式,运维团队问题处理的步骤、时间节点等。运维的目的不仅仅是消除问题,同时也是向客户输出知识的过程,通过指导、培训,使客户能充分掌握产品的使用,甚至能自行进行问题的定位与处理。 

6.3运维手册 

项目运维手册在项目上线后就需要整理,在验收前需要提供给客户,以便在项目运维过程中能及时进行问题处理,将出现问题时对业务的影响降低到最小。不同于蓝图、产品等相关文件,运维手册是一个需要不断完善的文档,在实际运维过程中,需要根据日常的运维情况将新出现的问题及时整理到运维手册中,一方面可以帮助客户更好的掌握产品的使用和问题的处理,同时也能为后续接手运维的人员可以更快速地熟悉工作。 

6.4知识传递 

知识传递是一个持续的过程,而且是贯穿在整个项目周期的,从前期调研甚至更早开始,就需要向客户、伙伴进行知识传递,包括对方案的理解、产品的应用、业务的融合、管理的方式等,需要让客户方、伙伴方了解方案、认可方案,才能保证在实施过程中更好地推动项目的实施过程。 

项目实施、培训、运维的过程也是知识输出的过程,需要不断向使用方进行知识的输出,使各方对集成底座有更深入的理解,并能够在实际业务过程中发现集成底座的优势,加强对集成底座的使用效率,使集成底座能真正发挥出在企业IT规划中积极作用,促进企业信息化的发展。 

集成底座方案以IDM、MDM、ESB产品为核心,为企业信息化建设搭建基础的、统一的、标准的、可复用的、易扩展的IT框架,在复用企业IT资产的同时也为后续的信息系统建设奠定基础。而作为标准的集成方案,目前集成底座已经满足了在不同项目中快速复用的条件,所以后续集成底座类项目大多数会采用产品 + 培训的模式,由伙伴方进行具体的实施落地,所以内部团队要熟悉集成底座的每一个环节,对于产品、流程、业务、场景等内容要由充分的理解,并把这些知识不断传递出去,提高伙伴方对集成底座的理解和认知,也能保证后续有更多集成底座类的项目顺利上线。 

以上是关于集成底座项目实施规程的主要内容,如果未能解决你的问题,请参考以下文章

集成底座项目典型数据下发方式对比说明

集成底座统一认证配置说明

集成底座POC演示流程说明

集成底座POC演示流程说明

集成底座与业务系统对接过程梳理

集成底座POC方案说明