产品经理在开发电子商务的后台管理系统（包括供应商管理，商品管理，财务管理，客服管理）中，一般都遇到过哪些问题呢？
我有一点疑问，为什么要进行重复做轮子的工作。对于一个互联网公司来说，对供应商管理，商品管理，财务管理并不精通的。其实应该把这些让管理软件公司来做的，在系统中开发相应的接口就好了。而且在网站初期，后端的
产品经理在开发电子商务的后台管理系统（包括供应商管理，商品管理，财务管理，客服管理）中，一般都遇到过哪些问题呢？ 我有一点疑问，为什么要进行重复做轮子的工作。对于一个互联网公司来说，对供应商管理，商品管理，财务管理并不精通的。其实应该把这些让管理软件公司来做的，在系统中开发相应的接口就好了。
而且在网站初期，后端的这些管理可以用人肉来处理，把流程摸透了，再进行系统规划和开发的。 很早之前做过一个供应链系统，就把之前遇到的问题简单说一下~~~~
1）商品采购：
一般情况下，一个产品会有N个供应商供货，不同时间段的供应商不同。选择哪家供应商，核价涉及哪些因素，如何解决不同供应商的同一种商品的核价问题？
2）库存管理：
从前台一个订单出库，就经历客服审核，订单发货，配送以及退货等各个环节。如何管理各个环节的库存关系？如何处理库存和采购之间关系，最大可能性降低库存成本？
3）配送管理：
配送是自行配送还外包给物流商？配送信息由谁导入系统？什么时间导入？用户查看物流信息时？配送中，出现退款情况，成本有谁承担等等
4) 结算：
这个依赖于公司内部是否有erp系统，进行商品进行入库和出库等。若没有，如果确定产品的采购价、实际购买价以及相关税率之间关系？如果在结算时，解决一笔订单多个商品的分拆问题？
5）商品管理：
价格：一个产品根据其性质不同，利润不同，产生溢价不同？如果建立一套机制或者定价策略，减少或者降低人工出错的成本
产品与商品：一般情况下，后台系统允许有且仅有一个产品，但可以有多个商品，如何建立产品与商品之间的关联，确保库存一致性？
6）订单管理
主要涉及一笔订单产生各个状态？有多少个状态？有谁触发这些状态？
细节还有很多，就啰嗦这些吧···· 信息、实物、账务 三者的边界一定要划分清楚。
另外产品角度一定要想清楚，订单驱动？商品驱动？财务驱动？这些都是系统设计的出发点。 1. 订单管理（最为重要）
用户看到的订单状态可能仅仅是对用户有效的，但是对于内部来说可能远远不够，例如客服的跟进状态？商家的跟进状态？网友的支付状态？商家的送货状态等……
2. 工作流的设计
在工作中主要做的是客服系统，如何触发任务？单一任务的处理状态与报表之间的关联？ 冗余信息是否会导致在某个工作环节上发生错误？是否会存在任务生成了，但是没有人处理的情况？
3. 报表的设计
报表要尽可能得简单（复杂的报表，打开5分钟，领导谁看）？ 报表是否可延迟？ 报表每个格子的计算规则是否与其他地方的统计是否一致？
4. 需求方一定是正确的吗？
由于是内部系统，需求方可能会经常性提出很多“无理”的需求，有些需求是“用户希望有的”，有些需求是“用户喜欢用的”，两者是不同的。
5. 避免频繁操作数据库
作为内部系统的产品经理，可能会被要求找程序员批量做某种操作：如订单状态变更、用户资料批量修改等。 这些非常规的操作，可能会为你将来带来无穷麻烦。 曾经为客服批量完成了某项任务，导致在做季度总结的时候，无法正确统计客服的绩效。
6. 批量性操作的设计
从功能上和代码上，谨慎再谨慎！要做好页面响应时间的估算，“全选”"提交"“提示”的设计，最好等做到系统日志的记录。 主要是信息如何交流与沟通使得内部流程更顺畅。
从流程上来说，是否有货，采购时间是什么时候，有多少货，用户下订单后何时处理，何时发货，发货后如何通知反馈客户，货款何时结算，万一有退换货如何进行处理。客服需要沟通什么，产品上下架的准则是什么，也许是产品停产，也许是其他 。
都是信息的交换问题。 只做过一个后台图片管理系统，总结一下犯过的错误，希望能借鉴：
选择正确的方式
我们在开始做一个项目时会自然而然地想到用B/S结构设计。但后台的需求往往繁杂，而且后台是给同事用，所以大可以考虑用多种方式解决。
砍断工作流
我们费尽千辛万苦从甲方那边确定的需求是一条又臭又长的工作流，而把这条工作流直接转化为需求就是悲剧的开始…… 工作流当中只有部分工作是适合做成产品的，要从中抽取出来。
商品的状态要细化，要记录各个状态变更的时间，另外要正确处理SKU与单件的关系，以及支持不同时期的商品成本计算，给出暂估成本比如：关税、增值税、运杂成本都是在不同时段计入系统进行来成本核算的；
2.订单管理
一定要规范操作流程，销售出库，退货入库两手抓
3.数据挖掘
商品周转率，商品在售率统计、报损类型分布，供应商的退货率，出库情况分析
4.财务结算
商品对账要记录指定期间的商品出入库情况，并要进行历史查询，所以一定要做好日志记录；
另外，避免直接修改数据库
如修改商品状态，一般的正常操作导致状态变更都会写入日志，如果冒然修改会直接印象历史数据的追溯，而且当商品绑定各种单据的时候联动关系实在太大，批量修改最好仅限于信息记录的更改，千万不要涉及流程任务产生的数据， 1.要知道同类的软件的优缺点。通过他的客人去了解。不要自己想像。
2。要十分清楚自己要什么样的系统。
3。和每个部门或者每个环境的负责人详细了解细节。
4。编好你的流程故事。包括所有的细节并想到做梦都在想。
5。故事告诉做软件的。要确定你说的意思是他接受的意思。
6。最好重复1-5。
这是我的经验。没法和你说会出现的问题。因为背景不一样。我知道没有耐心和不细心的做不好的。你是编故事的人。要想到别人没想到的。要想到别人没碰到的。 商品管理的问题最大，因为内部使用的人最多，用户看到的状态、员工看到的状态会很多，而且内部不同部门的员工都可能操作商品状态，这里面的协同很复杂，一定要理清楚场景，提供完善的状态图，否则时间一长，大家就混乱了做之前最好先想清楚两个问题：什么时候做？做到什么程度，也就是做成什么样？
原则上，月销售在千万以下没必要自己做这些系统。这个阶段最主要目标是熟悉并确定自己的业务流程。
电子商务的后台系统是以ERP为前提和核心再加CRM和BI系统。
ERP的重点是采购、仓库和财务管理，这几个模块考验产品经理对业务的熟悉和清晰程度的，同时，不可避免的会改造原有的业务流程。
所以，自己实施ERP的难点在于对原有业务的梳理改造并保证系统的可用性和扩展性，千万别被现状束缚了系统实现除了上面说到的，还有监控模块，由于操作人员可能带来的隐患还有便于管理监控，系统各个环节的监控必须充分和到位。我就说一块，订单系统中是否需要订单合并功能？
如果需要，订单中货品和运费是否是拆分开计算的？订单合并后运费如何处理，若消费者已经付款，合并后的多余运费怎么搞定？~B2C电子商务最全面解决的后台系统包括几个方面
1、进销存系统（线上下区分及结合）
前台结合的订单、产品、活动等属于简单开发 不谈论
2、BI系统 （BI包括所有流量、订单、商品、库存、发货等所有数据节点、亦包含全站的各种积分、优惠券、会员体系等分支）
3、仓储以及配送发货体系
4、客服系统及CRM的管理
5、财务对接及单独财务结算
6、数据管理及分析
一般整个架构的设计开发中的最常见问题是传统行业的内部ERP及CRM的对接利用
数据仓库的调用如何配对平台系统的权限
主要在于公司对于平台的重视层度。也就是协调内部系统对接是出现最多的问题
最大的问题在于你的系统开发完了，你的项目倒闭了。
电商行业，发展那么快，不可能什么都开发完了再来做，而是先凑合着用，边跑边穿衣服
管理思想决定管理目标，管理目标决定管理方式。遇到的问题会很多，所以我在想一个产品经理能否做到的问题；以实际的经验来说，如果一个产品经理没有进行过采购方面的培训，在后台设计就非常麻烦，比如对接供应商时后台需要生成哪些数据，哪些数据需要导出与对接供应商的（简单的比如后台需不需要增加税率及出单的功能），很多人都以为这些是技术人员应该处理的事情，但实际的过程中，将采购管理需求整理及提出还是所谓的产品经理，我的建议会是成立一个专责的工作组，这里更需要的角色是项目经理，不仅在于项目时间进度，也在于需求把控；
要让一个先期不怎么熟悉采购、客服及财务流程的产品经理处理这些事情，不如做好整体的技术框架，再考虑外包或者应用较成熟的第三方系统；等后期团队成熟，再修改。不然做出来东西一个是不能用，二个是反复修改；除非所处于的市场正是黄金市场，你无须为时间担忧。
问题很多，需要整体规划，局部侧重，关键是要跟公司的业务很好的衔接。下面复制一下我做的并且现在用的很好的一部分，这是一个社区和商城的综合，当然侧重于商城。独家资料，仅供参考，模精品无效！
========哥哥==========
商城商品管理（这里主要是商品采编人员使用，内嵌商品促销等）
商品管理 | 添加商品
品牌维护 | 供应管理
专题维护 | 制造维护
分类维护 | 收藏管理
商城进销存管理（这部分基本在订单操作的时候自动完成，大大减少工作量）
入库管理 | 增加入库
出库管理 | 增加出库
采购管理 | 采购申请
库存预警 | 目前库存
运费查询 | 物流管理（这里结合了我们的实际直接将各个物流公司的地域配送价格入库，下单时根据商品重量、自选物流、包装系数自动计算运费，好用）
商城员工客户管理（这里包含一些社区管理的）
员工管理 | 客户管理
会员管理 | 合并账户
在线用户 | 访问统计
文章管理 | 评论管理
商城加盟店管理（因为我们有在线加盟店，分配三级域名）
加盟用户 | 域名管理
加盟订单 | 加盟结算
淘宝数据 | 加盟库存
网站广告管理 （社区广告直接销售，哈哈）
广告类别 | 添加类别
广告订单 | 发布广告
广告统计 | 广告收支
友情站点 | 添加站点
其他管理选项（重点是日志功能）
升级日志 | 添加
站内短信 | 管理日志
文章收藏 | 更新
ＩＰ管理 | 添加锁定
商城财务管理（客户账务明细及余额台账，也包含了公司日常的财务流水，哈哈，发生的时候顺手记上，月底自动汇总出报表）
商城银行 | 银行科目
费用成本 | 财务科目
固定资产 | 摊销项目
1，了解业务
2，了解业务
3，了解业务
去用这些东西的人那里实际操作一下，看你的客户到底是每天在干什么。然后你就会了，不用别人教。我讨论一下财务系统：
这个问题我想了很久，我传统行业信息实施好多年了，从用友到SAP，对于财务系统而已，在传统企业来说，业务财务一体化，应该不是一个问题。
但是对于一个互联网公司而言，对于业务财务一体化，确实是很麻烦，起先是业务的疯狂增长，对于企业而言只要有高营收就可以了，所以慢慢的财务对于这个组织的地位每况愈下，只是做帐的。
说到这，大家应该知道产品经理会怎么想了把除了供应商没碰过，其他有幸都弄过，每个里面都有无数坑。
以淘宝和品牌独立b2c实物电商而言，最重要也是最难的无非订单，库存，促销三块。
1，订单模块，各种订单的状态，得弄清楚，正向订单逆向订单，款到发货订单，货到付款订单，全退订单，部分退订单，换货订单，拆单，关联订单，缺货订单，部分缺货订单…为了避免一些幺蛾子状态的产生，需要预先做一些业务上的规范和取舍，降低系统难度，别什么都想实现。你看淘宝不就这样么，哈哈哈。
例如:只退不换，只能换同款不能换异款，换货按照先退再售，优惠券一旦使用退单不退券，订单促销加权平均到订单内每个商品上退货时按照加权平均金额退款等等。
这里面还要注意订单流转状态变更一定要留日志，操作记录，有据可依。
还有一点，订单基本信息，一定要存下来，而不是去关联查询。
2，商品里面，主要坑在库存上。库存的同步机制，最大限度避免超卖。多渠道共享库存机制，渠道独占库存机制，低于某个共享库存阀值后的库存策略切换。
商品录入环节，就是看怎么给操作者省事了，看需要来做，就是各种变着花的录入。
3，客服，倒是还算好，业务部门的诉求主要来自于客服工作量统计，客服操作日志。多想就是客服的绩效。
4，财务，主要是对账用，没人会真用电商系统去做账，都是金蝶用友，这里就是个对库存帐和订单帐的问题，各种单据留全即可。订单纬度的销售订单，退货订单，财务纬度的收款单，付款单(退款单)，仓库纬度的发货单，收货单。
如果涉及到成本，得考虑同款不同批次成本不同，先进先出原则或者后进先出原则。
另外，如果你做淘宝的话，淘宝的发票问题，神马直通车发票，平台扣点发票，支付宝发票等，尤其是直通车和淘客的发票…
补充:
聊得越细越有话题！
1.预售话题，财务方面我们是按照实物出仓做节点，按照应收应付来算销售业绩。预售，实物还没有出仓，所以算作代收。实物到货并发出订单以后，算业绩。同理，货到付款订单，因为货品已出库，所以按照应收金额算业绩，到货后用户拒收算退单。这部分，财务在拉业绩的时候，只拉已发货订单即可。现金管理部分，我们系统真还不管。
2.优惠券，红包，促销活动等，我们是按照订单中每个商品售价，把促销和券加权平均到每个商品上，记一个优惠，一个实收金额。这样退换货的时候也不重新计算促销了，省事，虽然有一定的风险被钻空子，但还好了，客户体验好，用户也没有想象中那么恶心。
3.满赠优惠券活动，折让不算在本单里，全部算在使用这张优惠券的订单里面，这样清楚些，也好做。
4.这个活动到底赚不赚钱，这个话题真的好大，一般运营都算不明白。而且，商家考虑的是这一盘货赚了多少，而非这个单一的活动或者优惠券赚不赚。从商品运营角度，有些商品卖一单亏一单，但是能引流量。有些商品，就是奔着赚钱去的，很少打折。这就是整个一盘货的定价策略了，28法则适用于此。如果非要核算一个促销活动，或者是一张优惠券赚了多少钱，也能做啊，在订单里面拉一段时间内使用了某张优惠券的订单，或者是参加了某促销活动的订单，订单里面都能算出来啊，因为我在订单数据里面把一切能存下来的都存了，什么单品实收金额，单品成本的，一算毛利就行。但大多数还都是看一段时间内所有订单的毛利率。
5.品牌方真的也有产品经理，有幸我就是。不过真的很少有公司像我待过的两家公司一样，电商前后台都自己做开发，公司养了产品设计开发测试运维。其中一家传统服装品牌电商，光电商it五六十人，高峰90多人。线下it更夸张，连pos都自己写的。总共加起来，我大it部门不算外包一百七八十号。
6.大多数传统企业，还都是外购系统，什么管易百胜e店宝，官网商城来个ecshop。不过，系统这玩意跟做衣服一样，量身定做的肯定比外面标准产品更适合你，因为是贴着你的业务走的，抗折腾能力也强，你说哪不行，咱改啊，今天你提需求，我立马开搞，明天给你看demo原型，再等一礼拜我上线了，外购系统估计还在看合同算人天砍价扯皮呢。
而且在网站初期，后端的这些管理可以用人肉来处理，把流程摸透了，再进行系统规划和开发的。 很早之前做过一个供应链系统，就把之前遇到的问题简单说一下~~~~
1）商品采购：
一般情况下，一个产品会有N个供应商供货，不同时间段的供应商不同。选择哪家供应商，核价涉及哪些因素，如何解决不同供应商的同一种商品的核价问题？
2）库存管理：
从前台一个订单出库，就经历客服审核，订单发货，配送以及退货等各个环节。如何管理各个环节的库存关系？如何处理库存和采购之间关系，最大可能性降低库存成本？
3）配送管理：
配送是自行配送还外包给物流商？配送信息由谁导入系统？什么时间导入？用户查看物流信息时？配送中，出现退款情况，成本有谁承担等等
4) 结算：
这个依赖于公司内部是否有erp系统，进行商品进行入库和出库等。若没有，如果确定产品的采购价、实际购买价以及相关税率之间关系？如果在结算时，解决一笔订单多个商品的分拆问题？
5）商品管理：
价格：一个产品根据其性质不同，利润不同，产生溢价不同？如果建立一套机制或者定价策略，减少或者降低人工出错的成本
产品与商品：一般情况下，后台系统允许有且仅有一个产品，但可以有多个商品，如何建立产品与商品之间的关联，确保库存一致性？
6）订单管理
主要涉及一笔订单产生各个状态？有多少个状态？有谁触发这些状态？
细节还有很多，就啰嗦这些吧···· 信息、实物、账务 三者的边界一定要划分清楚。
另外产品角度一定要想清楚，订单驱动？商品驱动？财务驱动？这些都是系统设计的出发点。 1. 订单管理（最为重要）
用户看到的订单状态可能仅仅是对用户有效的，但是对于内部来说可能远远不够，例如客服的跟进状态？商家的跟进状态？网友的支付状态？商家的送货状态等……
2. 工作流的设计
在工作中主要做的是客服系统，如何触发任务？单一任务的处理状态与报表之间的关联？ 冗余信息是否会导致在某个工作环节上发生错误？是否会存在任务生成了，但是没有人处理的情况？
3. 报表的设计
报表要尽可能得简单（复杂的报表，打开5分钟，领导谁看）？ 报表是否可延迟？ 报表每个格子的计算规则是否与其他地方的统计是否一致？
4. 需求方一定是正确的吗？
由于是内部系统，需求方可能会经常性提出很多“无理”的需求，有些需求是“用户希望有的”，有些需求是“用户喜欢用的”，两者是不同的。
5. 避免频繁操作数据库
作为内部系统的产品经理，可能会被要求找程序员批量做某种操作：如订单状态变更、用户资料批量修改等。 这些非常规的操作，可能会为你将来带来无穷麻烦。 曾经为客服批量完成了某项任务，导致在做季度总结的时候，无法正确统计客服的绩效。
6. 批量性操作的设计
从功能上和代码上，谨慎再谨慎！要做好页面响应时间的估算，“全选”"提交"“提示”的设计，最好等做到系统日志的记录。 主要是信息如何交流与沟通使得内部流程更顺畅。
从流程上来说，是否有货，采购时间是什么时候，有多少货，用户下订单后何时处理，何时发货，发货后如何通知反馈客户，货款何时结算，万一有退换货如何进行处理。客服需要沟通什么，产品上下架的准则是什么，也许是产品停产，也许是其他 。
都是信息的交换问题。 只做过一个后台图片管理系统，总结一下犯过的错误，希望能借鉴：
选择正确的方式
我们在开始做一个项目时会自然而然地想到用B/S结构设计。但后台的需求往往繁杂，而且后台是给同事用，所以大可以考虑用多种方式解决。
例如：复杂的交互最方便还是C/S结构，上传最方便还是FTP，简短而近的沟通最好还是靠吼……
砍断工作流
我们费尽千辛万苦从甲方那边确定的需求是一条又臭又长的工作流，而把这条工作流直接转化为需求就是悲剧的开始…… 工作流当中只有部分工作是适合做成产品的，要从中抽取出来。
例如：当审核未通过变成一个小概率事件时，完全不需要为此建立一条拘审的工作流，只需要一封邮件或一个电话就能解决。1.库存管理
商品的状态要细化，要记录各个状态变更的时间，另外要正确处理SKU与单件的关系，以及支持不同时期的商品成本计算，给出暂估成本比如：关税、增值税、运杂成本都是在不同时段计入系统进行来成本核算的；
2.订单管理
一定要规范操作流程，销售出库，退货入库两手抓
3.数据挖掘
商品周转率，商品在售率统计、报损类型分布，供应商的退货率，出库情况分析
4.财务结算
商品对账要记录指定期间的商品出入库情况，并要进行历史查询，所以一定要做好日志记录；
另外，避免直接修改数据库
如修改商品状态，一般的正常操作导致状态变更都会写入日志，如果冒然修改会直接印象历史数据的追溯，而且当商品绑定各种单据的时候联动关系实在太大，批量修改最好仅限于信息记录的更改，千万不要涉及流程任务产生的数据， 1.要知道同类的软件的优缺点。通过他的客人去了解。不要自己想像。
2。要十分清楚自己要什么样的系统。
3。和每个部门或者每个环境的负责人详细了解细节。
4。编好你的流程故事。包括所有的细节并想到做梦都在想。
5。故事告诉做软件的。要确定你说的意思是他接受的意思。
6。最好重复1-5。
这是我的经验。没法和你说会出现的问题。因为背景不一样。我知道没有耐心和不细心的做不好的。你是编故事的人。要想到别人没想到的。要想到别人没碰到的。 商品管理的问题最大，因为内部使用的人最多，用户看到的状态、员工看到的状态会很多，而且内部不同部门的员工都可能操作商品状态，这里面的协同很复杂，一定要理清楚场景，提供完善的状态图，否则时间一长，大家就混乱了做之前最好先想清楚两个问题：什么时候做？做到什么程度，也就是做成什么样？
原则上，月销售在千万以下没必要自己做这些系统。这个阶段最主要目标是熟悉并确定自己的业务流程。
电子商务的后台系统是以ERP为前提和核心再加CRM和BI系统。
ERP的重点是采购、仓库和财务管理，这几个模块考验产品经理对业务的熟悉和清晰程度的，同时，不可避免的会改造原有的业务流程。
所以，自己实施ERP的难点在于对原有业务的梳理改造并保证系统的可用性和扩展性，千万别被现状束缚了系统实现除了上面说到的，还有监控模块，由于操作人员可能带来的隐患还有便于管理监控，系统各个环节的监控必须充分和到位。我就说一块，订单系统中是否需要订单合并功能？
如果需要，订单中货品和运费是否是拆分开计算的？订单合并后运费如何处理，若消费者已经付款，合并后的多余运费怎么搞定？~B2C电子商务最全面解决的后台系统包括几个方面
1、进销存系统（线上下区分及结合）
前台结合的订单、产品、活动等属于简单开发 不谈论
2、BI系统 （BI包括所有流量、订单、商品、库存、发货等所有数据节点、亦包含全站的各种积分、优惠券、会员体系等分支）
3、仓储以及配送发货体系
4、客服系统及CRM的管理
5、财务对接及单独财务结算
6、数据管理及分析
一般整个架构的设计开发中的最常见问题是传统行业的内部ERP及CRM的对接利用
数据仓库的调用如何配对平台系统的权限
主要在于公司对于平台的重视层度。也就是协调内部系统对接是出现最多的问题
最大的问题在于你的系统开发完了，你的项目倒闭了。
电商行业，发展那么快，不可能什么都开发完了再来做，而是先凑合着用，边跑边穿衣服
管理思想决定管理目标，管理目标决定管理方式。遇到的问题会很多，所以我在想一个产品经理能否做到的问题；以实际的经验来说，如果一个产品经理没有进行过采购方面的培训，在后台设计就非常麻烦，比如对接供应商时后台需要生成哪些数据，哪些数据需要导出与对接供应商的（简单的比如后台需不需要增加税率及出单的功能），很多人都以为这些是技术人员应该处理的事情，但实际的过程中，将采购管理需求整理及提出还是所谓的产品经理，我的建议会是成立一个专责的工作组，这里更需要的角色是项目经理，不仅在于项目时间进度，也在于需求把控；
要让一个先期不怎么熟悉采购、客服及财务流程的产品经理处理这些事情，不如做好整体的技术框架，再考虑外包或者应用较成熟的第三方系统；等后期团队成熟，再修改。不然做出来东西一个是不能用，二个是反复修改；除非所处于的市场正是黄金市场，你无须为时间担忧。
问题很多，需要整体规划，局部侧重，关键是要跟公司的业务很好的衔接。下面复制一下我做的并且现在用的很好的一部分，这是一个社区和商城的综合，当然侧重于商城。独家资料，仅供参考，模精品无效！
========哥哥==========
商城商品管理（这里主要是商品采编人员使用，内嵌商品促销等）
商品管理 | 添加商品
品牌维护 | 供应管理
专题维护 | 制造维护
分类维护 | 收藏管理
商城进销存管理（这部分基本在订单操作的时候自动完成，大大减少工作量）
入库管理 | 增加入库
出库管理 | 增加出库
采购管理 | 采购申请
库存预警 | 目前库存
运费查询 | 物流管理（这里结合了我们的实际直接将各个物流公司的地域配送价格入库，下单时根据商品重量、自选物流、包装系数自动计算运费，好用）
商城员工客户管理（这里包含一些社区管理的）
员工管理 | 客户管理
会员管理 | 合并账户
在线用户 | 访问统计
文章管理 | 评论管理
商城加盟店管理（因为我们有在线加盟店，分配三级域名）
加盟用户 | 域名管理
加盟订单 | 加盟结算
淘宝数据 | 加盟库存
网站广告管理 （社区广告直接销售，哈哈）
广告类别 | 添加类别
广告订单 | 发布广告
广告统计 | 广告收支
友情站点 | 添加站点
其他管理选项（重点是日志功能）
升级日志 | 添加
站内短信 | 管理日志
文章收藏 | 更新
ＩＰ管理 | 添加锁定
商城财务管理（客户账务明细及余额台账，也包含了公司日常的财务流水，哈哈，发生的时候顺手记上，月底自动汇总出报表）
商城银行 | 银行科目
费用成本 | 财务科目
固定资产 | 摊销项目
1，了解业务
2，了解业务
3，了解业务
去用这些东西的人那里实际操作一下，看你的客户到底是每天在干什么。然后你就会了，不用别人教。我讨论一下财务系统：
这个问题我想了很久，我传统行业信息实施好多年了，从用友到SAP，对于财务系统而已，在传统企业来说，业务财务一体化，应该不是一个问题。
但是对于一个互联网公司而言，对于业务财务一体化，确实是很麻烦，起先是业务的疯狂增长，对于企业而言只要有高营收就可以了，所以慢慢的财务对于这个组织的地位每况愈下，只是做帐的。
说到这，大家应该知道产品经理会怎么想了把除了供应商没碰过，其他有幸都弄过，每个里面都有无数坑。
以淘宝和品牌独立b2c实物电商而言，最重要也是最难的无非订单，库存，促销三块。
1，订单模块，各种订单的状态，得弄清楚，正向订单逆向订单，款到发货订单，货到付款订单，全退订单，部分退订单，换货订单，拆单，关联订单，缺货订单，部分缺货订单…为了避免一些幺蛾子状态的产生，需要预先做一些业务上的规范和取舍，降低系统难度，别什么都想实现。你看淘宝不就这样么，哈哈哈。
例如:只退不换，只能换同款不能换异款，换货按照先退再售，优惠券一旦使用退单不退券，订单促销加权平均到订单内每个商品上退货时按照加权平均金额退款等等。
这里面还要注意订单流转状态变更一定要留日志，操作记录，有据可依。
还有一点，订单基本信息，一定要存下来，而不是去关联查询。
2，商品里面，主要坑在库存上。库存的同步机制，最大限度避免超卖。多渠道共享库存机制，渠道独占库存机制，低于某个共享库存阀值后的库存策略切换。
商品录入环节，就是看怎么给操作者省事了，看需要来做，就是各种变着花的录入。
3，客服，倒是还算好，业务部门的诉求主要来自于客服工作量统计，客服操作日志。多想就是客服的绩效。
4，财务，主要是对账用，没人会真用电商系统去做账，都是金蝶用友，这里就是个对库存帐和订单帐的问题，各种单据留全即可。订单纬度的销售订单，退货订单，财务纬度的收款单，付款单(退款单)，仓库纬度的发货单，收货单。
如果涉及到成本，得考虑同款不同批次成本不同，先进先出原则或者后进先出原则。
另外，如果你做淘宝的话，淘宝的发票问题，神马直通车发票，平台扣点发票，支付宝发票等，尤其是直通车和淘客的发票…
补充:
聊得越细越有话题！
1.预售话题，财务方面我们是按照实物出仓做节点，按照应收应付来算销售业绩。预售，实物还没有出仓，所以算作代收。实物到货并发出订单以后，算业绩。同理，货到付款订单，因为货品已出库，所以按照应收金额算业绩，到货后用户拒收算退单。这部分，财务在拉业绩的时候，只拉已发货订单即可。现金管理部分，我们系统真还不管。
2.优惠券，红包，促销活动等，我们是按照订单中每个商品售价，把促销和券加权平均到每个商品上，记一个优惠，一个实收金额。这样退换货的时候也不重新计算促销了，省事，虽然有一定的风险被钻空子，但还好了，客户体验好，用户也没有想象中那么恶心。
3.满赠优惠券活动，折让不算在本单里，全部算在使用这张优惠券的订单里面，这样清楚些，也好做。
4.这个活动到底赚不赚钱，这个话题真的好大，一般运营都算不明白。而且，商家考虑的是这一盘货赚了多少，而非这个单一的活动或者优惠券赚不赚。从商品运营角度，有些商品卖一单亏一单，但是能引流量。有些商品，就是奔着赚钱去的，很少打折。这就是整个一盘货的定价策略了，28法则适用于此。如果非要核算一个促销活动，或者是一张优惠券赚了多少钱，也能做啊，在订单里面拉一段时间内使用了某张优惠券的订单，或者是参加了某促销活动的订单，订单里面都能算出来啊，因为我在订单数据里面把一切能存下来的都存了，什么单品实收金额，单品成本的，一算毛利就行。但大多数还都是看一段时间内所有订单的毛利率。
5.品牌方真的也有产品经理，有幸我就是。不过真的很少有公司像我待过的两家公司一样，电商前后台都自己做开发，公司养了产品设计开发测试运维。其中一家传统服装品牌电商，光电商it五六十人，高峰90多人。线下it更夸张，连pos都自己写的。总共加起来，我大it部门不算外包一百七八十号。
6.大多数传统企业，还都是外购系统，什么管易百胜e店宝，官网商城来个ecshop。不过，系统这玩意跟做衣服一样，量身定做的肯定比外面标准产品更适合你，因为是贴着你的业务走的，抗折腾能力也强，你说哪不行，咱改啊，今天你提需求，我立马开搞，明天给你看demo原型，再等一礼拜我上线了，外购系统估计还在看合同算人天砍价扯皮呢。
责任编辑：
