确认过眼神，读了这篇房地产跟投文章将少走很多“弯路”！
随着跟投制度的推进，跟投项目越来越多，工作量越来越大，跟投信息化就成为一种必然。
根据赛普爱德地产研究院的推算，一个跟投项目全过程要与跟投人发生包括签订投资协议、跟投额度确认、返本与分红等36次交互。
一次交互对不同的跟投人传递信息可能不同，如果一个项目有1000个人跟投，那么一个项目就要发生3.6万次不同的信息交互，10个项目的交互量就是36万次，按跟投项目全过程两年计算，一年的交互量就是18万次。
如此大的工作量若通过手工处理则效率低，较难保证及时准确，资料与数据较难留存。
跟投信息化作用
标杆房企如万科、招商蛇口、金地在跟投信息化已积累丰富经验，从实践来看，跟投信息化主要有以下作用：
一、落地跟投制度
跟投制度的核心是与项目经营结果直接相关的人员跟投项目分享收益、承担风险。
跟投信息化就是要落地这个核心，让每个强制跟投人员按制度规定的额度跟投项目，不能有遗漏，而且跟投金额符合要求，强制跟投人员的投入金额高于最低跟投资金要求；如果配杠杆，杠杆的应用也应与跟投人的岗位相符。
不论是基于共享，还是共担的跟投制度，应该让跟投人能够清楚看到所投项目以及投入的本金、分红。唯有跟投收益与项目经营情况挂钩，跟投收益看得见，才能强化跟投的激励和共担的效果。
二、服务跟投人
跟投涉及的人员数量多、敏感度高，对跟投人服务、信息交互工作量大，跟投信息化应该通过系统提升对跟投人的服务效率和水平，这个系统不同于企业内部应用的业务管理系统，更应强调服务，让跟投更简单高效，员工才更愿意跟投。
★跟投额度认购、确认
规模较大的企业，每个月有几个新开项目。每个项目成百上千人跟投，每个跟投人的额度认购、确认工作比较繁琐，认购金额的改动也比较频繁。
没有信息化系统之前，一般通过电话、短信、微信、邮件等多种方式汇集给跟投管理人员，信息量非常大，容易出错，如果漏记其中一个人的金额改动，对账时难免会出现错误。
★跟投协议签订
每个跟投人投一个项目需要签订两三份协议，每个项目几千份协议，跟投协议的打印、盖章、邮寄，需要花大量的时间和精力，信息化应该解决这个问题，电子协议的签订在个人投资领域已经是成熟的做法，不存在法律问题。
使用跟投信息化之前，跟投人不方便查询跟投的本金、每个项目的返本／分红、项目投资回报、综合回报率等相关信息，如果要查询，只能找跟投管理员。跟投管理员要面对全公司（或分子公司）全部跟投人的查询。
★信息展示
跟投金支付之后，项目开发过程中如果跟投人想了解项目进展，只能向知情的相关人员打听，或者等待公布，如没有合适的跟投平台公布项目进展信息，往往容易被淹没在公告板或通告栏中。
因此，对跟投人的服务包括跟投信息服务、认购、协议签订、返本、分红、跟投收益查询等，信息化系统可以使得信息透明，效率提高。
跟投信息化常见误区
一、打通项目经营数据
有观点认为，跟投信息化需要将跟投项目的进度信息与经营系统中的项目经营数据打通。如果这样做，需要将项目核心的经营指标通报给跟投人，每个项目跟投人的规模成百上千，不利于项目经营敏感数据的保密。对数据敏感的跟投人，可能还要花不少精力去解释各类疑问和数据归集方法。
其次，在跟投制度或协议中，规定跟投人不参与项目经营和决策。跟投人属于财务投资人身份，报告结构性数据比较合适，不适合报告项目详细的经营数据。
第三，跟投返本是在达到一定条件（通常是资金峰值或现金流回正）后一次性或逐步返还，具体的返本时机要考虑未来时间内项目开发现金需求，无法跟项目经营数据（主要是存量现金流）建立直接的对应关系，不能说项目资金是跟投本金3倍以上就可返还全部本金，每个项目的情况千差万别，项目经营数据在跟投信息化中无法直接应用。
而跟投分红是预测的项目利润，预提一定的比例发放，预提的比例要考虑项目可能的利润、支付情况和未来现金流需求，需要人工修订经营系统中获取的项目经营数据后再做决策，无法与项目经营数据直接建立对应关系。
在跟投实践中，万科、金地均表示不认同跟投与经营数据打通。
二、在线进行跟投相关测算
跟投测算主要包括跟投收益、跟投返本与分红测算。
跟投测算的口径不同于财务口径，是基于管理口径，但又要比管理口径更保守，避免跟投预分红大于实际应分配利润，所以碧桂园才有跟投分配超额兜底机制，超分多分部分由区域总经理和财务负责人承担。
如果在线进行跟投测算，需要重新构建新的测算模型，跟投制度推出的时间不长，跟投规则、测算方法还不稳定，新模型的稳定性不高，即便做出这套模型，由于每个区域或整个公司只有1-2个财务人员，模型的应用人员较少，还不如线下对相关数据调整来做跟投测算来得便捷灵活。
跟投制度在行业中推行多年，目前还没有哪家企业的跟投测算工作在线上完成。
跟投信息化除要结合企业的跟投制度和主要部门的需求，还要借鉴行业经验。万科是跟投制度的引领者、跟投信息化的先行者，4年多来持续开展跟投信息化建设，累计优化需求800多次，实现了10多个版本的更新迭代，积累了丰富的实践经验，值得后来者学习、借鉴。
