如何快速地切入一个新领域和熟悉一个新的IT业务系统？

　　今天谈下如何快速的切入一个新领域，包括从事IT行业的人员如何快速的去熟悉一个新的IT业务系统方面的话题。比如你原来做供应链管理类业务系统，那么当前你要去做MES系统的需求或研发，那么你如何快速的熟悉MES系统业务和功能？
　　在前面谈学习方法和模式的文章中，我经常谈到工作以后的学习和你在学校阶段的学习差异很大，重点体现在如下两个方面。工作后学习是问题和目标驱动的，不是原理驱动的工作后学习是快速短周期迭代的
　　所以你不是一开始就去系统的学习全面的学习理论，通过理论来掌握某一个方法或技能，而是应该是从粗到细，基于问题驱动的快速迭代学习并在实践过程中逐步去扩展和深入。从如何快速的切入一个新领域说起
　　这里还是拿IT行业和信息技术领域来举例说明。
　　在信息技术领域，任何新领域都是已有知识领域，已有技术和研究成果的进一步组合和创新，新领域一分解到底层你会发现全是已有技术，方法和工具。这些很可能都是我们熟悉的内容，而新领域仅仅是对已有知识和技术的进一步组合，形成一套完整的方法和技术来解决新的问题。
　　第一步：大量的阅读形成概念模型
　　当接触一个新领域的时候，首先是大量的阅读，在一开始没有机会实践的时候，那只有先补充和学习基础的理论，了解新领域的知识体系和结构，了解新领域所涉及 到得关键技术。将新领域的内容和自我已有的技术实践和经验总结进行匹配和映射。纸上谈兵有很多种，但是没有任何相关领域知识和实践的积累，那么接触新领域有些知识根本无法理解；如果已有历史相关实践积累，那么接触新领域知识至少从理论和方法上做到理解，这种理解虽然可能是停留在理论上，但是至少理论上的方法 能够通过已有的相关实践做到很好的串通。也就是我们说的至少在理论上自圆其说，完整和严谨。
　　大量的阅读包括了新领域所涉及到基础技术原理知识的阅读，也包括了新领域应用案例方面的阅读，虽然你还没有开始实践，但是阅读别人的实践，结合基础理论和自我已有的相关经验积累，你可以更加深入的时刻我准备如何去实践？我后续实践的思路是如何的？先模仿再超越，模仿本身可能没有错，错的地方是知其然不知其所以然得模仿，模仿或实践完了还是一头雾水或无法贯通。
　　大量的阅读以泛读为主，泛读的目的是快速地了解新领域，形成新领域知识的大框架，了解知识点之间的关联，了解新领域做事情的方法和方式，再细化的技术层面的内容一开始不需要了解，抓住核心并搭建框架始终是我们强调的进入新领域的第一步。
　　第二步：实践-问题和目标驱动深入理解
　　第一步完成后，重点将转移到提出问题和目标，以问题和目标驱动对某一个方面进行深入理解。或者是根据实际项目或客户的需要，根据前期新领域的学习和业界的经验，构想实践的方案和流程。
　　在这一步的重点就是实践，通过实践来验证方法和可行性，对于不可行的方法根据自我实践进行修正和完善。在实践过程中任何一个问题点，你可能都需要深入地去了解相关知识点，定义和分析问题，最终解决问题，只有最终问题解决后你才能够得到最终需要的经验积累。
　　实践的目的是为了验证我们的假设和我们参考的理论和方法，实践本身是理论知识在项目实际场景下的具体应用，理论本身可能是多种现实场景的抽象，而实践又是将理论回归到现实场景中，以自我证悟理论+场景下通过实践能否得出我们期望的结果。
　　实践的目的是修正方法论形成自我适用的经验和模式，一方面是通过分析和解决问题加深对某一个分支上面理论知识的理解。第一步在广度，而第二步在深度。广度是深度的基础，深度是广度的价值体现。
　　接入新领域，只做第一步是很多咨询顾问常有的问题；只做第二步是很多技术人员常有的问题。而任何新领域的学习和深入，唯有闻思修的不断迭代和演进。如何短期内快速的熟悉一个IT业务系统？
　　如果你已经有IT行业的工作背景，那么对于原来你没有接触过的一个新业务领域或新的IT系统，你应该如何快速切入？在这里我们假设你已有有一定的IT行业工作经验，业务和技术双方的积累，在这种情况下的新系统快速切入可以从如下三个大步骤入手。
　　在这三个步骤中你可以明显看到和我在讲思维框架模型中谈到的认知模型，事物静态分析和动态分析，动静结合的分析逻辑的思路是一致的。
　　第一步：粗粒度的全局了解
　　接触一个全新的业务系统，首先要搞清楚这个业务系统主要是支撑什么样的业务？而对于支撑的业务本身又有两个核心内容，即核心的业务流程是如何的？核心的业务对象模型是如何的？在这个了解清楚后可以继续了解这个业务系统大致会有哪些核心的业务功能模块，业务模块之间的相互关系是如何的？已经如何衔接的。
　　有时候了解到这个层面可能还不够，你还需要了解这个业务系统可能是支撑端到端业务流程或共享业务数据的一部分，那么还需要了解到这个业务系统或支撑的业务在端到端流程中所处的位置，该业务系统和上游业务和下游业务的关系，相互间的协同和接口。
　　业务系统支撑了什么样的业务，存储了哪些核心业务对象和数据，这是对一个业务系统最基础的全局理解。
　　第二步：动态了解-流程模型
　　在对业务系统有了一个全局的理解后，需要开始进一步考虑流程模型方面的内容。注意在这里指的流程模型不是指工作流或人工审批流模型，而是指业务流程模型。或者说了解业务系统本身在分析设计中所涉及到的业务建模方面的内容。
　　业务建模或业务流程模型的了解需要解决的问题是，一个业务系统为何会存在这些业务模块，这些业务模块之间是如何进行协同来支撑业务流程的。任何业务模块都会有输入和输出，了解清楚业务模块的输入输出后就能够比较清楚业务模块之间是如何串接和集成来支撑上层的核心业务的。
　　如果一个业务系统按SOA思想来建设，你可能会看到有哪些上层的核心业务模块，核心的领域服务层和底层的数据模型层，核心的业务模块本身是如何调用核心领域服务来进行协同和衔接的。只有清楚了业务流程才可能理解清楚业务模块之间的协同和集成关系，否则你看到的是孤立的业务模块，业务模块和业务流程之间出现断点而无法真正想清楚业务模块间如何协同来支撑业务的。
　　如果一个业务系统本身是流程型的业务系统，这些流程又大量是审批流为主，那么即使审批流定义再复杂，整个业务系统本身也是简单的，因为不存在上面所说的大量业务模块间协同情况。
　　第三步：静态了解-数据模型
　　对于一个业务系统的复杂往往体现在两个方面，一个方面是本身业务模块间的协同和交互复杂，一个是底层的数据模型和关系复杂。在解决了第一个层面的动态分析问题后，就需要开始考虑第二个层面的数据模型了解层面的问题。
　　任何业务流程，模块间动态的协同最终都将持久化到数据库中，成为数据库中的数据表和数据表之间的关联依赖关系，映射关系。业务系统前面谈到过或者是以流程为中心的业务系统，或者是以数据为中心的业务系统，对于数据为核心的业务系统必须理解底层的数据模型。这种数据模型的理解首先是要理解元模型结构，这种结构不是简单的单个数据对象，而是多个数据对象之间的关联关系，映射关系，层次关系等。正是由于数据之间有这些关系，而形成了一个复杂的数据网络。
　　对于数据模型的理解基本可以分为如下几种，一种是单对象的结构，包括主从，层次等各种结构；然后才是对象和对象之间的关联依赖结构，如一对多，多对多结构等。对于较为复杂的业务系统，你可能还会看到为了保证底层数据模型的可扩展性和灵活性，往往在数据模型层会根据面向对象的思路做进一步的抽象，那么在这种情况下还必须等将OO的对象模型和面向结构的数据库模型共同来参考理解，以分析和了解清楚最终数据存储的方式，数据存储后最终呈现的方式。
　　第四步：动静结合-关键业务分析
　　个人理解，对于新切入一个新的业务系统，如果能够理解到这一步，基本就可以对一个业务系统有一个比较全面的理解和认识。首先是了解业务流程和模块间协同，然后是了解数据模型和数据间关系，最后则是真正的根据核心业务来进一步理解在流程协同过程中最终数据的落地存储。由动态的业务流程驱动的最终静态数据的存储落地和关系的建立。只有这样流程和数据的分析最终才会融合为一个整体。
　　对于关键业务的分析你会看到，对于这些关键业务需要理解清楚究竟涉及到哪些模块的协同，在模块的协同过程中最终会产生哪些核心的数据，或者说会更改哪些核心数据的状态或数据间的关系。真正你需要关注的往往不是单个数据对象中某些数据熟悉的变更和修改，而更多的是关注核心业务流程驱动下，数据对象状态的修改，数据对象间关联关系的修改，数据间映射模型的调整等。
　　对于一个完整的业务系统，按道理只要有基本的数据对象维护功能即可，但是要真正能够支撑业务，你会看到数据对象中的关键属性，关键依赖关系的变更，最终都是由上层的业务模块和流程来支撑的，那么你就必须要能够真正的理解所有的核心业务流程最终对底层数据模型造成的影响。