关于内控设计的个人经验总结Word文件下载.docx

关于内控设计的个人经验总结Word文件下载.docx

《关于内控设计的个人经验总结Word文件下载.docx》由会员分享，可在线阅读，更多相关《关于内控设计的个人经验总结Word文件下载.docx（17页珍藏版）》请在冰豆网上搜索。

——分形__切块，参阅4D场景中的3D立体。

——钻取，指改变维的层次，变换分析的粒度，包括向上钻取（rollup）和向下钻取（drilldown）。

——关联规则和粒度，分形学。

——层次分析法和系统工程论。

——OLAP联机分析处理和数据挖掘。

——处于0维的点往单一方向延伸会变成1维空间的线段；

1维空间的线段往垂直方向延伸会变成2维空间的平面；

平面的垂直延伸是3D立体；

将3D立体变成一个点，划一根带箭头的直线，当点在直线上延伸就会变成4D；

将4D压缩为一个点，同样划一根带箭头的直线，当点在直线上延伸就会变成5D；

依此类推，将n维度空间压缩为一个点，然后让其在一根带箭头的直线上延伸，就会得到n+1维事件，即在n+1维生物看来，n维世界的一切仅仅是n+1维世界的一个点而已，点无法理解其它点，其实就是n维生物无法感知n+1维的事件。

见下图。

上图可见，3D场景其实就是进行2D切片，4D场景其实就是进行3D切块，n+1维场景其实就是进行n维场景的点延伸。

将一页一页的文档装订成册，会变成一份文件，我们会发现这本文件是3D的，只不过Z轴是有限整数的延伸，翻开它是一页页的文档，如同切片般，每一页文档如同一个平面。

当走入档案室时，会发现一份一份的文件陈列在一起，我们会发现这是一个4D场景，每抽出一份文件就像是切块；

然后，你可以试着想象一下，把一个时间段（月/季度/年份）的文件压缩为一个点，或者换一个角度，将一个部门的文件视为直线上的一个点，这根直线就是公司的不同部门的集合。

按照高维控制低维的原则设计

一般而言，业务进程的方向/顺序基本遵循从高维向低维转变的规则，个别地方可能会存在局部调整，但总的趋势是不容置疑的，如同水从高处流向低处。

每个基本要素视为1维直线上的点，如果要素是n维的，那么要素的规则排列就是n+1维。

——业务进程的规则叠加变成业务流程，任意打碎一项业务进程，假设是2D延伸，即将一个点变成一个面（使用2个属性同时描述），如果是3D延伸，则是将一个点变成一个立体（使用3个属性同时描述），如果是1D延伸，则是将一个点变成一根直线上的多个点集合（使用1个属性同时描述）。

泛函——将函数中的任一变量延伸为一个子函数

泛函，函数中嵌套函数，实际上就是描述母函数和子函数之间的相互关系。

C语言中的嵌套函数、指针、指针变量等概念应用到内部控制体系的设计中是很有启发意义的。

体系实际上是一个泛函，其变量是各个子系统，各个子系统又由组件（部件/子件/零件）组成，每个组件不也是一个包含很多变量的函数吗？

是的。

最终，我们可以逐层分解得到只有变量的一个泛函，即将嵌套函数全部变成变量的泛函。

嵌套函数并非C语言独有，Excel中的函数也可以实现，最多可嵌套7层，即整个函数体系是7维的。

连excel都运用维度结构的函数来描述世界，你还犹豫什么？

必须懂得分形学

康托尔三分集，将闭区间[0,1]，去掉中间的1/3，留下[0,1/3]和[2/3,1]，再分别去掉这两段中间的1/3，变成等长的4段……重复这个过程无穷多步，就得到了康托尔三分集。

康托尔集有无穷多个点，占据[0,1]区间，长度却为0，是一个分形，具有非整数维数、自相似性等分形的特点。

设想从一个线段开始，根据下列规则构造一个Koch曲线：

　　1．三等分一条线段；

　　2．用一个等边三角形替代第一步划分三等分的中间部分；

　　3．在每一条直线上，重复第二步。

　　Koch曲线是以上步骤地无限重复的极限结果。

举例

note过程—方法—展开—学习

层级

以数学建模思想设计的内部控制体系

（用例—业务建模—系统建模—功能建模）

具体描述

备注

体系

system

业务视图

指导方针

（相关方利益最大化=Σ结果+Σ水平+Σ趋势+Σ重要性）

指导方针是针对不同背景而设置的，例如财务控制模式、业务控制模式、混合控制模式等，指导方针可以是股东利益最大化、相关方利益和谐、利润最大化、顾客满意度最大化、3C竞争体积最大化等等。

指导方针体现出来的是体系总要求，总要求是通过各个系统（子系统）正常输出功能来达成的。

财务系统（由n个会计事项组成的处理系统，也可说是n项业务组成的处理系统）

多个子系统在指导方针、指导原则、总要求等纲领性文件的统领下有机运作，发展成为自组织——内控体系。

1

子系统

model

功能视图

控制目标

（Σ各子系统功能输出的风险控制目标）

控制目标是确定各子系统（部委）功能输出的总目标，或者说是总输出功能，例如，资金组的系统功能是款项收支，税务组的系统功能主要是输出税费计缴合规和税负控制效益，资产管理组的系统功能主要是输出财产安全完整等等。

子系统就是由部分同类会计事项组成的小处理系统，即小功能。

由此可延伸，扁平化的组织是以负责哪些业务流程为划分原则。

例如资金组、税务组、费用组、预算管理组、成本管理组、财务报告组、资产管理组、往来账管理组，等。

子系统主要是输出各项功能。

流程就是做到组织功能描述层面即可，关于如何发挥功能由下一层级的项目（组件）来描述。

就像，服务器CUP可以协调各工作站的CPU一样，调用是通过一份框架协议来控制的，服务器CPU可以影响多少个工作站的CPU，这就是适用范围。

适用范围

（Σ适用对象）

系统是由各个子件组成的，这里的系统输出功能和子件输出功能是一样的，适用范围是说明控制目标可以覆盖哪些子件，即子系统包括哪些子件，即集团各部委功能输出总目标可以覆盖哪些子公司，例如，税费申报审批流程适用对象是所有法人公司的税费申报。

例如2核CPU、3核CPU、4核CPU等等，大CPU输出功能和小CPU输出功能是相同的，大CUP输出功能是小CPU输出功能的累加，当然这个累加可以有一些小小的调整。

适用对象就是回答，系统要求哪些子件输出同样功能。

由于适用对象是存在于一定范围内的，因此习惯上就把适用对象说成适用范围，准确的说法应该是XX对象或者某范围内的XX对象。

1.1

控制项目

component

业务流程图

控制办法

（Σ控制措施）

由于实施的是全面风险管理形式的内部控制，因此此项实际上就是针对流程中各节点（作业活动）风险而实施的具体控制措施，或者说是防止作业活动出现不可控的偏差而实施的管制措施，控制办法通常体现为作业路线的背景/噪音，流水线的灯光/温度。

小处理系统是由多个事件的处理元件组成的。

资金组（银行付款管理流程、货币资金安全管理办法、利润分配管理流程等），税务组（税费申报审批流程、发票管理办法、税务筹划流程、税负控制流程、所得税会计作业指引等），财务报告组（财务报告管理流程、关联交易管理办法），……

项目（组件），即对于各项功能该如何发挥进行详细描述。

需要综合运用全面风险管理8项基本要素，必须全面遵从法律法规、管理政策和会计政策，并充分运用卓越绩效、ISO、PDCA、BPM、ERP等各种先进管理理念。

控制组织

（Σ组织单元）

这里的控制组织并非职能组织，而是流程中各个组织单元组的集合，各个组织单元可以是一个人，也可以是一个小团队，每个组织单元不一定都是一个职能部门的，也不一定是一个公司，即组织单元可以跨部门、甚至跨公司。

总之，控制组织，是针对控制项目而言的所有参与组织单元的集合。

当然，如果组织单元全部是一个职能部门的，那么控制组织就是该职能部门，在这种情况下控制组织等于职能组织。

增值处理

（Σ作业活动）

各项作业活动的集合就是增值处理，即各个步骤，或者各项工序，例如利润分配管理流程包括利润分配建议、利润分配建议审批、编制利润分配方案、审议利润分配方案、执行利润分配方案、披露利润分配方案等。

基本事件

（Σ事件单元）

例如，对于资金组而言，银行付款是一连串事件的组合：

收到用款审批单——打印出空白付款票据——收到签审OK的付款票据——收到银行回单

注意

设计内控体系实际上是设计一个大系统，大系统是各个子系统组成的，而每个子系统又是由多个子件组成的，每个子件又是通过作业机制来完成的，而每项作业机制又是控制办法作用于作业路线形成的，作业路线就像流水线，它是由控制组织和增值处理组成的一幅2维空间的场景，增值处理是X轴，各项作业活动是X轴上面的点，控制组织是Y轴，各个组织单元是Y轴上面的点。

控制办法也可以被打包变成作业路线上面的一个点，或多个点，其实控制办法更像是流水线上面的灯光，因此控制办法更像是作业路线的背景/噪音。

内控体系必须以分维理念设计，即须以非整数维的理念来表达系统功能流程图，体系——子系统——控制项目，控制目标和系统功能是一体的，犹如时间和空间是一体的，但是空间的变化是时间箭头驱动的，即控制目标是驱动系统功能实现的箭头。

如何适用范围设计多个法人公司或职能组织，则控制项目是分维结构的，如果是一个法人公司或职能组织，则控制项目是整数维。

相关知识

C语言，混沌理论、协同学、自组织、他组织、突变论、系统论、信息论；

泛函、嵌套函数、切片、切块；

分形学、降维分析、多维分析、钻取；

数学建模，数据粒度，数据仓，UML统一建模语言；

卓越绩效评价、ISO、相关方利益最大化、PDCA、EPC等等。

note结果—水平—趋势—重要性

深入研究系统的内部结构及其相互关系，并用不同维度的视图描述出来，就是系统设计。

内部控制体系设计与全面风险管理框架

Usecase用例

静态结构

Office

办公系统

局域网

（网络协议和拓扑结构是指导方针）

高维生物大厦

ARIS屋式财务系统

-1

models

活动图、协作图、组件、状态

Wordexcelaccess

PowerPointVisioOutlookPublisherInfoPath

服务器、工作站、网络、路由器……

资源视图、组织视图、信息视图、功能视图/过程视图

-2

components

部署、序列

例0#菜单栏——工具栏——工作内容区——状态栏

例1#将word菜单栏展开将得到开始-插入-页面布局-引用-邮件-审阅-视图-开发工具-设计-布局

……#

0#输入—处理—输出

1#扫描输入—处理—存储—输出

2#键盘鼠标输入—处理—输出

3#外部信息交换输入—处理—输出

4#U盘/光盘输入—处理

5#无线传输

6#触摸屏

7#摄像头

……

低维生物

生活场景

假设有一部透明的玻璃电梯上下升降，坐在电梯里的人和每一楼层的人，就好像是3维空间生命体和2维空间生命体，2维人在所在楼层的小房间里活动。

必须充分了解面向对象的UML建模方法：

事件—角色—交互

业务建模——系统建模

从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；

其次根据需求建立系统的静态模型，以构造系统的结构；

第三步是描述系统的行为。

其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包含包）、对象图、组件图和配置图等五个图形，是标准建模语言UML的静态建模机制。

其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。

它包括状态图、活动图、顺序图和合作图等四个图形，是标准建模语言UML的动态建模机制。

因此，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

标准建模语言UML的重要内容可以由下列五类图（共9种图形）来定义：

第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。

第二类是静态图（Staticdiagram），包括类图、对象图和包图。

其中类图描述系统中类的静态结构。

不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。

类图描述的是一种静态关系，在系统的整个生命周期都是有效的。

对象图是类图的实例，几乎使用与类图完全相同的标识。

他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。

一个对象图是类图的一个实例。

由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

包由包或类组成，表示包与包之间的关系。

包图用于描述系统的分层结构。

第三类是行为图（Behaviordiagram），描述系统的动态模型和组成对象间的交互关系。

其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。

通常，状态图是对类图的补充。

在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。

而活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。

第四类是交互图（Interactivediagram），描述对象间的交互关系。

其中顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；

合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。

除显示信息交换外，合作图还显示对象以及它们之间的关系。

如果强调时间和顺序，则使用顺序图；

如果强调上下级关系，则选择合作图。

这两种图合称为交互图。

第五类是实现图（Implementationdiagram）。

其中构件图描述代码部件的物理结构及各部件之间的依赖关系。

一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。

它包含逻辑类或实现类的有关信息。

部件图有助于分析和理解部件之间的相互影响程度。

配置图定义系统中软硬件的物理体系结构。

它可以显示实际的计算机和设备（用节点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。

在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

UML是UnifiedModelingLanguage（统一建模语言）的缩写，是使用面向对象概念进行系统分析设计的工具，它主要是用一些规范、形象的图形来描述业务或系统—也就是称之为建立业务模型或系统模型，用UML建模，既是用UML建立业务模型和系统模型。

业务模型是指用UML描述业务，即画出业务（business）用例图，当然，这里说画用例图，不应仅仅理解为画出图形，用例图应附有详细的业务说明。

业务用例如下所示（注意：

在RationalRose中业务人员和业务用例和系统用例在图形上有所不同，业务用例用一个椭圆加一斜杠表示。

）。

一般说来，业务建模只需要画出业务用例图即可。

在判断一项业务的复杂程度和大小规模时，常常可根据业务用例数量来判断，因此，在业务建模时，每个业务用例应合理分解，得到的业务用例应在业务复杂程度，规模大小方面相差不多，以便于对业务的评估和进行系统开发。

系统模型是指用UML描述系统，系统模型是在分析业务模型后得到的，通常，系统模型用用例图、类图、时序图三种图来描述即可，如果功能较为复杂，也可以用活动图和状态图来对某一部分功能进行特别描述。

系统用例图是从软件功能的角度去描述软件系统，因此和业务用例是不同的，表示如下

系统用例图不是必须的，但它能帮助我们理解系统模型。

类图是系统模型中最重要的图形，是UML中唯一能产生程序代码的图形，类图描述了对象的属性和方法，如下入所示：

类图示系统建模必不可少的图形，如果做得好，可由类图生成程序的结构，然后由程序员按照类图生成的程序结构去细化程序，实现功能。

时序图是对类图的补充，它描述了对象的方法的调用情况，时序图和类图的联系最为紧密，在时序图中添加一个消息（我一直不明白为什么要称之为消息），如下图中的inputStudents（），则会在消息所指向的对象类图中的类—Register自动生成一个方法inputStudents（）（但在时序图中删除一个消息，则不会自动删除类图中对应的方法）。

时序图虽不能生成程序，但它对系统功能的操作能较为清楚地描述，相对类图（类图称为静态模型）而言，它是一种动态的描述，因此称为动态模型。

有一种和时序图相同功能的图叫做协作图，在RationalRose可以用F5键自动转换这两个图。

总结，建模分为业务建模和系统建模，其中：

1、业务建模即建立业务模型—业务用例图；

2、系统建模即建立系统模型—用例模型（用例图）、静态模型（类图）、动态模型（时序图）。

UML图形中英文对照（RationalRose软件）：

1、 

用例图—UseCaseDiagram

2、 

类 

图—ClassDiagram

3、 

时序图—SequenceDiagram

4、 

协作图—CollaborationDiagram

5、 

状态图—StatechartDiagram

6、 

活动图—ActivityDiagram

7、 

组件图—ComponentDiagram

8、 

配置图—DeploymentDiagram