[实施]根据K3快速实施EAS

上传人:飞*** 文档编号:8346131 上传时间:2017-09-27 格式:DOC 页数:41 大小:1.99MB
返回 下载 相关 举报
[实施]根据K3快速实施EAS_第1页
第1页 / 共41页
[实施]根据K3快速实施EAS_第2页
第2页 / 共41页
[实施]根据K3快速实施EAS_第3页
第3页 / 共41页
[实施]根据K3快速实施EAS_第4页
第4页 / 共41页
[实施]根据K3快速实施EAS_第5页
第5页 / 共41页
点击查看更多>>
资源描述

《[实施]根据K3快速实施EAS》由会员分享,可在线阅读,更多相关《[实施]根据K3快速实施EAS(41页珍藏版)》请在金锄头文库上搜索。

1、根据 K/3 快速实施 EAS朱涛2006-12-19一、前言我们现在有大量 K/3 老用户,随着客户的业务及公司规模的发展,升级 K/3 老用户到EAS 上有着大量的商机,因此实施时如何好好利用用户使用 K/3 的基础以便快速切换到EAS、快速实施 EAS 是一个很有意义的专题。升级 K/3 到 EAS 可以有两种方式,一种是直接升级 K/3 的数据到 EAS 中(EAS 正在研发相关工具),另外一种是从应用模式转换的角度进行升级,直接在 EAS 中重新初始化,根据用户在 K/3 中的应用情况快速实施 EAS。本文所说的方法属于第二种。实施一个项目前期需要经过项目准备、项目定义、业务调研、蓝

2、图设计等细致、大量的工作,如果客户本身的 ERP 基础比较薄弱,或者业务流程也不够清晰的话,那么实施的进程可能会比较长,需要大量的时间进行调研、规范流程和培训,但是如果客户本身就是K/3 的老用户,那么我们可以好好的利用以前实施 K/3 时打下的基础,使得快速实施 EAS成为可能。现在 EAS 中财务和供应链的模块功能以及基本覆盖 K/3(除了制造、计划部分),所以这为快速移植 K/3 应用到 EAS 中提供了很大的可能。以下本文从项目组织与产品分析两个大的方面提供一些指南和建议方案。注意:快速实施不仅仅是产品本身,还有一个重要因素的是项目组织与控制的策略,例如确认客户方关键人物、沟通方式、培

3、训方式等等,应该重点关注。二、项目组织2.1、业务调研2.1.1、快速了解应用现状 搜集以前实施 K/3 时的相关项目文档,找以前的 K/3 的实施人员或者找客户方经常使用 K/3 的操作人员了解 K/3 的使用情况; 到客户方现场自己查看 K/3 的账套、基础资料设置、模块应用情况等;关键需要了解的是:客户目前使用了 K/3 的哪些模块?(如果客户是集团性的企业,还要注意了解到主要分支机构的使用情况)客户目前使用了 K/3 每个模块的哪些关键业务流程?客户对 K/3 有哪些进一步的诉求?也就是客户选择 EAS 替代 K/3 的主要原因是什么?根据了解到的这些情况,整理出 K/3 基本应用情况

4、调查表,画出用户主要业务流程图,这样就能迅速基本掌握用户的基本业务以及目前的信息化水平和程度,然后由 EAS 实施顾问据此判断实施 EAS 的主要方向和关键点。根据这些初期的成果,再跟用户交流,让客户明确现有流程是否需要改动和优化,同时提出金蝶的建议措施和方案,如果用户需要改动、优化或者补充业务流程(例如在 K/3中没有管到的),那么在调研的 K/3 的业务流程上在进一步补充和完善。如果不根据 K/3 的应用情况进行调研,那么调研花的时间长不说,也不容易聚焦目标,难以迅速得到成果。2.1.2、找到客户方关键人物找到客户方项目组的关键人物也是非常重要的,实施的每个阶段成果都是需要客户方关键人物签

5、字确认的,如果不了解关键人物的诉求和做事方式,平时不注意多私下沟通,那么最后实施成果的确认将会变得很艰难。无论是实施阶段、实施方案、流程梳理、蓝图整理之类的工作成果都应该多跟客户方关键人物私下沟通,以便先取得上层的支持,才能保证项目的顺利发展。有什么困难,也应该跟客户方关键人物在私下事先多多沟通,而不是未经跟关键人物沟通就摆到正式场合来讨论,会影响对方表态进而导致项目拖期。2.2、项目准备2.2.1、项目定义一定要分阶段实施在项目定义的时候最好能说服客户把实施的第一阶段目标定义为首先把用户在 K/3 的流程全部搬到 EAS 中来。围绕着这个阶段目标,第一期的工作会比较明确,把在 EAS 中实现

6、 K/3 的关键流程作为第一期的工作目标,由 EAS 实施顾问对比 EAS 的功能点进行分析,如果有 EAS 中没有覆盖到的功能点和流程,马上整理出关键需求分析表,提交总部。对于用户对 K/3 的进一步诉求,以及用户期望用 EAS 中能够实现的管理诉求等等,整理出来作为第二期的实施目标。关于项目阶段目标的定义需要跟客户仔细交流,关键要取得他们的认可,说明这样快速实施的好处。否则如果范围不够聚焦,目标太大,那么实施难节奏难免拖沓。同时难以鼓舞双方的士气,没有成就感。2.2.2、硬件方案给出专家建议业务调研以后,应该立刻给用户一个关于网络设置、硬件(服务器、客户端硬件升级)、部署方式(例如集群)的

7、一个建议方案,帮助用户同时开始准备硬件环境。否则,用户因为不太清楚 EAS 的硬件需求情况,难以在前期做出有效的响应,我们主动给出一个硬件方案,或者专家建议,能够让用户心里放心。同时,EAS 对硬件要求比较高,应该尽量建议用户用高一些的配置。否则,后期如果涉及到性能问题会导致被动。2.2.3、培训方式先高层、再普及;先概念、再操作;业务调研以后,应该马上形成初步实施方案(至少在概念上),同时着手进行对客户方进行培训,这个培训不要大规模,可以非正式的,主要针对客户方关键人物、项目组领导以及核心人员进行培训, 这时候的培训主要要说清楚 EAS 的一些关键概念、基本模式,已经对项目实施方案的设想,以

8、便整得客户方关键人物的认同。如果不先对客户高层、关键人物进行培训,在后面进行业务蓝图确认的时候,客户方关键人物会可能因为不了解 EAS 的基本架构和概念而难以理解,影响成果确认;同时因为业务蓝图还没有确认,进行大规模培训也不合适。对于客户方普通的操作人员,可以给客户先预装一个测试环境,让他们先熟悉熟悉 EAS,为后期大规模培训打好基础。2.2.4、数据准备快速准备基础数据。实施 EAS 需要的重要基础数据(如组织架构、科目、物料、客户、供应商、仓库等)可以从 K/3 中导出整理出来,然后跟客户确认:K/3 中的基础数据规则是否在 EAS 中可用?是否需要调整?例如:组织架构是否有调整?明细科目

9、是否需要调整?物料、客户、供应商的编码规则是否需要调整?仓库的设置是否有调整?等等,如果客户需要调整,在 K/3导出的基础数据整理,也会方便很多。三、产品分析3.1、明确差异明确 K/3 和 EAS 的差异,确定实施策略。K/3 和 EAS 在功能上类似程度比较高(EAS 继承了 K/3 的很多功能设计思路),但是在整体架构上差异很大,这表现为:K/3 主要是针对单体企业应用的,而 EAS 主要是针对集团企业设计的,因此 EAS 在设计上更多考虑的是集团企业各组织、分支机构、部门之间的业务协同和集团上下级之间的集中控制与管理。这个巨大的差异体现在基础数据、业务政策控制以及业务流程上 K/3 和

10、 EAS 都会有所不同。在升级 K/3 到 EAS 的实施过程中必须注意到这一点,一方面 EAS 实施人员要能清楚K/3 和 EAS 的差异,二是要针对这种差异对分支机构实施人员以及客户进行重点的培训。3.2、集团管理要想快速升级 K/3 到 EAS,首先就要了解清楚用户现有的或者期望的集团管理模式。K/3 的集团管理:K/3 的集团管理是通过单独的集团管理账套来控制、分配下级的基础资料,实现统一汇总控制的需要,是一种比较松散的控制方式,技术上是基于账套间的复制与同步,业务上集团管控的力度不强,管理粒度不可调整,业务协同无法保证。EAS 的集团管理:在 EAS 中的集团管理模式是有着丰富的业务

11、层次支持的,这也是跟 K/3 有着很大不同的。在 EAS 中这样一个数据大集中的模式中如何根据用户的实际业务场景最大限度的发挥集团管理的优势?如何做到纵向的集中控制、横向的业务协同?考虑以下几个方面:1、用户的集团管理模式:简单来说现在用户的集团管理模式都是介于集权和分权之间的混合型,有些可能偏集权一些,有些可能偏分权一些,按照 EAS 的标准分类大致是:财务控制性、战略控制性、运营控制性,这三种模式的集中控制力度是逐渐增强的。对于大型多元化集团下的多个子集团以及子子集团,它们的集团管孔方式可能又是上面三种的一种或者几种的组合,但是一般都有偏向;2、集团管理模式如何体现?上述的三种模式我们通常

12、可以在业务上总结出来它们的特点,例如:财务控制型一般是多元化的集团企业,或者是控股型集团企业,总部对下面只关系财务结果控制,只关心下属子公司的盈利情况,一般不参与经营决策等;而战略控制型可能则要更加深入下属子公司的资金运营、关键人事控制、统一品牌形象、战略营销等等;至于运营控制型则是一种比较集权的强权总部模式,深入到下属子公司的业务运营的方方面这些模式在 EAS 中的体现方式,最终会跟几个关键要素挂钩:A、组织架构:包括管理单元的划分(需要考虑划分粒度如何控制?)、业务组织的划分(需要考虑到业务政策在业务组织上的层次以及集团虚体报表展现的需要)、委托关系(各业务组织之间如何协同);B、主数据:

13、需要考虑哪些主数据需要集中管理?每一种主数据设置在哪个 CU 层次上?需要往下分配到哪些 CU 上?(主数据的管理策略体现了:一:业务集中管理的粒度和力度,二:集团统一虚体报表查询的穿透度)C、业务流程:集团的业务流程跟单体最大的差别就在于要求各下属子公司、分支机构、各组织、部门之间的高度协同,需要明确用户有哪些协同的流程?在 EAS 中对应到各子系统中如何实现? 以下分别说明这些关键要素的升级策略,并附示例说明。3.3、组织架构K/3 组织架构:K/3 的组织架构是每个公司一个单独的账套、每个公司单独一套组织架构,基本上是公司部门这样的二级体系。EAS 组织架构:EAS 的组织架构是针对集团

14、企业设计的,数据大集中模式,把集团企业内所有公司、分支机构以及组织单元都纳入到一个组织架构体系中,以行政组织为依托,并抽象出业务组织作为业务活动开展和业务政策的载体,提供多业务组织视图作为统计和汇报的口径,是一个“单组织架构树、多业务视图”的组织架构模型。K/3 的组织架构到 EAS 的组织架构:升级 K/3 到 EAS 的过程中,组织架构不能照搬,也无法照搬,比较可行的方法是:1、因为 K/3 的组织架构基本上是以行政组织来设置的,因此可以首先把 K/3 各个账套中的组织架构树导出来(如果客户是集团的话),拼在一起组成一个集团范围的行政组织架构树作为 EAS 的基本组织单元树(基本上也是按照

15、公司部门的方式)。2、跟客户确认这棵基本组织单元树是否有调整(因为客户可能因为业务变化需要调整组织架构,趁着实施 ERP 也有可能有所调整,因此必须跟客户确认);如果有调整根据用户的需要进行调整;注意:跟用户探讨“公司部门”是否有调整即可,先不必涉及到业务组织,例如事业部、成本中心之类;3、在这棵组织单元树上标明独立核算的财务组织(可能是法人公司,也可能不是);以上这三个步骤是明确用户的行政组织架构树,即明确:公司部门的行政组织架构体系树。明确了这个以后,再在这棵树上划分出 EAS 的业务组织:1、根据用户的主数据(科目、客商、物料)共享程度以及管理模式确定 CU(管理单元)的划分;注意:以最

16、小的共享范围确定 CU 的粒度;例如客户的物料可能是全集团统一管理,但是客商需要各个法人公司自己管理,那么 CU 的粒度必须以客商的共享范围为准,但是主数据实际设置在哪个 CU 层次跟 CU 的粒度划分不要混为一谈(见后面的基础数据差异分析);2、再结合用户的实际业务流程、对业务政策管理的需要以及对虚体报表的展现要求,划分出采购组织、销售组织、库存组织、HR 组织等重要的业务组织的虚体和实体,并且根据业务协同关系和核算关系指定委托关系;关于 EAS 的组织架构的详细使用请参考相关的产品手册和指南。示例 1:亚华乳业组织架构的升级策略亚华乳业行政组织架构树亚华乳业总部亚华乳业集团望城分公司培益乳业城步分公司财务部望城液态奶厂行政部奶源部质保部市场部保温奶销售部常温奶销售部财务部行政部奶源部质保部城步乳品厂南山乳品厂其他公司高管财务总部信息部行政总部总经理办公室技术中心审计监察部陈旗指挥部采购部基地管理部办公室望城奶粉厂外协部奶粉销售部市场管理部市场部办公室服务部办公室销售部审计部华中大区华南大区华东大区

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 解决方案

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号