供应链系统开发(二)

供应链系统开发(二)

基本要素(确定调研方向,即确定参与系统的角色)

  • 上游供货商
  • 下游采购商
  • 资金提供商
  • 商品
  • 信息掮客/平台

以上是构成现代供应链的几个基础要素

要达成交易需要的几个步骤(业务流程分析)

  1. 下游采购商提出采购商品
  2. 下游采购商提出用款需求
  3. 下游采购商提出指定供货商/或者不关心
  4. 平台发布信息
  5. 平台撮合商品
  6. 平台撮合资金需求
  7. 平台撮合供应商

如下故事可以将场景闭环(业务场景分析)

  1. 客户向平台提出采购需求
  2. 平台分析需求,若仅有采购需求(直营)
    1. 从自有平台信息中寻找可撮合的交易对象
    2. 若存在则撮合交易
      1. 平台与供货商确定配送方式
      2. 客户付款
      3. 平台确认付款后,通知/直接将货物配送到指定地点
      4. 平台通知客户提货
      5. 客户通知平台提货完成
      6. 三方票据结算
      7. 故事结束
    3. 若不存在则
      1. 与客户沟通让其提供参考供应商
      2. 平台考察客户提供供应商,若准入则添加供应商至平台信息返回故事2.1
      3. 若不允许准入,则故事结束
  3. 若还有融资需求(垫资代采业务)
    1. 从自有平台信息中寻找可撮合的资金提供商
      1. 若存在则撮合交易
        1. 平台与资金提供商确定资金占用费用
        2. 平台与资金提供商确定供应商是否准入
        3. 平台与资金提供商确定商品是否准入
        4. 平台向客户返回费用协商结果及供应商,商品准入结果(项目信息)
        5. 若客户同意项目结果,则签署合同返回故事2.1
        6. 若客户不同意则返回3.1继续执行,直到所有资金商都无法满足客户需求
    2. 若无,则故事结束

到了这一步则系统的概设完成

参与角色与参与要素(业务场景涉及的表单、文件、票据等分析)

对照直营故事来细化
1. 询价单
2. 供应商目录
3. 商品目录
4. 采购合同
5. 销售合同
6. 采购订单
7. 销售订单
8. 发票
9. 通知
对照垫资代采故事细化
1. 资金提供商目录
2. 项目信息
3. 垫资代采合同
4. 与客户确认单据
按照此思路逐项分析,直至形成一个业务需求文档

近期总结

近期总结

问题

  1. 每个人都感觉自己非常忙却产出非常的少
  2. 从我这个角度观察,每天有大量的废话时间,尽管废话时间是与客户交流的
  3. 主管人员缺少决断却没有人能够站出来说背起责任
  4. 我仍然是缺少项目管理经验,同时还有分出时间来分析任务和分派任务至开发人员

问题的分析

  1. 从产出少的角度举个例子
    首先是我们的需求没有人做管理,每个人都围着需求说明书在转圈,没有一个富有项目管理经验的人能够明确的说,好的,我们这个文档做到这里,可以了,更多的情况是,你们这个文档不行啊,太不丰满,继续去摘要输入输出流程描述,不然对不起那几百万的钱。
    以上事实得出一个结论是,缺少文档管理及写作方面的人才
  2. 每个人都感觉自己非常忙
    这个的问题是我们前期参与项目的几个人,对着同一个文档,各自不同的部分,做了非常多的重复工作,举个例子是,客户的商品管理,前后出了十个版本,没有一个版本是和客户核对过的。
    这个问题的结论是,在缺乏项目管理经验的状态下,对于项目进度及内容的失控
  3. 废话时间这个问题
    废话指的是什么呢,是客户自己无意识中在发散,但是我们这边需求调研人员没有抓住自己的工作主要目的,亦即确认客户需求,客户天花乱坠的吹,我们静静的旁边听,或者是在旁边,嗯,是的,好的,没问题,您听我解释,而正常的情况应该是,大家针对目前的目标,针对性的,比如说630我们只要A需求落地上线,而A中需要拆分成几个不同的过程或者是需求,主导权应该要在我们开发系统的人手上。
    这个问题的结论是,主导项目管理开发的人员缺少决断,并且没有意识到整个项目的拖延是因为自己的没有决断导致的
  4. 缺少决断,没人背起责任,这就很清晰了,我在项目开展的第三周,反复提出,已有的不成熟的文档也最好能尽快和客户对接,通过客户的帮助来完成我们的文档,我的提议不一定是好的方案,但是却被很粗暴的驳回(三次),同组另一个同事也曾提出和我一样的意见,驳回的理由很苍白,我的做法是互联网做法,在我们公司不成立的,不能这样搞,在项目依旧进展缓慢的情况下,我其实也已经心灰意冷了,正常来说,在事情出了风险的情况下,只要能推进项目进度的做法都应该是可取的
    这个问题,我认为是领导在制度缺失的情况下,在压力下做出了不正确的做法,他在沿用了他曾经经历过的安全的做法
  5. 缺少项目管理经验,这个责任在我,我在这一个月内没有成长起来,例如CMMI实践操作文档我也是最近一周才去看

我提出的解决方案

  1. 从总公司抽调两个具有专门技能的人才
    1. 具有丰富的项目管理经验的人一名
    2. 具有现有框架开发及设计经验的人一名
  2. 需要以上人员扮演保姆或者是老师的角色
  3. 需要有个人提出来,出错在我,你们放心干

技术无关

有意思的一点是,其实是每个人看起来差异不大,但是人与人通过语言交流真的特费劲,有的人喜欢做什么事情都要先解释一番,有的人很急躁。
抓住一个主要矛盾是,在项目尽可能的规范下,尽可能的快速推进事物。
每个人的立场不同关注点不同,心平气和,放平心态

从需求到代码落地

业务需求分析

1.     调研需求宿主的原有业务

2.     调研需求宿主的诉求

3.     调研需求宿主是否由清晰的规划

业务分析阶段

1.     协助需求宿主梳理原有业务

2.     协助需求宿主新增业务

3.     协助宿主将新增和原有业务合并梳理并确立开发任务

业务需求转化开发需求

待完成

 

首先的首先

调研客户的现状,输出产物,现有流程图+要素表

然后要反复与客户确认流程图是否与客户达成了公式

接着才是将现有流程+客户诉求分解成功能点~!!!!!!!!!!!!!

供应链金融的玩法

中间厂商指的是在生产销售中既非供应链上游又不是供应链下游,但一般而言,对外宣称是掌握核心科技的那帮人(是的就是吐槽格力)我们称之为C

举个例子:

宝马公司相对于钢材,轮胎厂商就是C

供应链C是将整个生产链条串起来的关键

供应链负责从上游(原料厂商)获得生产原料

生产完毕之后再卖给下游厂商或直接消费者

因为生产和销售之间有很大的时间差,于是供应链金融是如下玩法

因为中间厂商相对于上游厂商拥有技术壁垒,那么对于银行来说这就是有抵质押物或者说信用很好

那么中间厂商就有高额度的授信。

中间厂商将其中一部分授信给予了上游厂商,用于采购原料和生产,上游厂商给予授信额度利息这笔钱的利息

下游厂商向中间厂商订购商品,还是因为时间差的原因,回款会很慢,那么下游厂商会向银行借贷,直接全款购买所有销售产品,每当销售完一件产品后,就支付银行本金及当期利息

这就是供应链金融

C向上游厂商下订单,因为上游的流动资金很少(为什么少另外再说),那么需要大量的资金,但是向银行直接借贷的成本又非常高,那么一般是向C借用其银行授信额度。其抵质押品为货品提单,因为法律认定提单是合法合规的抵质押标的物,那么C就可以从银行借到钱,然后再借给上游厂商。其中产生的利息是来自于上游厂商向C借的钱,最终上游厂商需要的交付物有,利息,货品提单的所有权

下游比如说4S店,需要从C中购买产品,同时4S店也不可能有大量的流动资金,同样需要向银行借贷,此时利息是付给银行的,那么其抵质押物是C直接给予4S的发票,4S每还清一个发票的货款,那么,银行就将发票归还至4S,因为发票涉及到4S的税务计算。故而发票是具备强大的约束力的,可以当作抵质押品标的物

融资租赁中的三方角色

出租人

供货商

承租人

出租人负责融资,提供金融服务

供货商只提供生产资料

承租人是向出租人借钱,然后直接在供货商提货

故而三方分别两两签订不同的合同

比如出租人与供货商签订的是购买合同

出租人与承租人签订的是借钱的合同

承租人与供货商签订的是货物生产的规格

什么是融资租赁

1.传统租赁:

出租人判断市场需求,购进租赁物,通过租给不同客户以获取利润

2.租赁:

通过借出资产而获得利润的活动,比如说典型的租赁行为:租房子

我们可以看出以上是两方的互动,出租人承担了所有的市场风险(出租房屋也有风险)

有风险,那么就要有转接风险。

风险有哪些呢,比如承租人无法支付租金,承租人携款跑路

那么对于出租人来说这就是风险

那么这种风险对于出租人来说如何化解

我们可以参考期货的做法,即让承租人直接将资产的价格锁定,产权归承租人。(开始了复杂金融行为)

因为出租人无法评估风险。我们将出租人评估风险的职责分摊至一个第三方,这个第三方只评估承租人是否有足够能力支付。

相应的在债券市场上就出现了评级机构,比如对某公司支付能力评为A级,或者AA级等等。资金方就可以根据信用或者支付能力就可以给承租人借款来全资租借/购买资产。

这种情况下,出租方提前将收益锁定

长期风险就转移至资金方

同时资产折旧转移至承租方

毛选2

读矛盾

矛盾的定义

按照毛选里的说明,我们可以对其表述的矛盾做一个定义,即使得事物发展或者称之为运动的因素称之为矛,使得事物不发生改变或者运动称之为盾。

但在毛的文章中,矛盾这个词往往有着一些感情色彩,即总有一个是攻另一个是守,而事实上如果不带感情色彩的词语描述即为以下描述:

什么是事物

在现代生产中,我们一般不称之为事物,而应称之为一个系统(System)

换成现代语言

毛泽东关于矛盾的思想可以表述为:

任意一个系统都存在两个相互作用的因素,一个使系统发生变动,另一个使得系统不变,系统的变化是两个因素交互或者说是互为作用的结果。

每一个系统都可以用他们上述所述的两个相互作用的因素进行描述或者说定义。

因为每个系统都由这两个因素定义,又因为这两个因素不一定相同那么,每个系统本质上都不一定会相同

综上,任何系统都具有两个可以定义它的因素,故而这是系统的普遍性,而又因为因素多种多样,而且组合起来更是花样繁多,那么系统又具有特殊性。

因素的定义

任何能使系统发生交互的都可以算作是因素

毛选1

做事要有一个目标,这个目标用数学的语言就是目标函数,我们要对目标函数优化就需要清楚函数的性质,了解到函数在不同入参的情况下的变化,换言之,要认清自己的优劣势避免盲目的取最优化的结果,从而换取全局上的人最优,此乃认清自我的真正本质

妄图用短时间击破英语是不可取的,但目标也不应该设置的太长,而应实事求是的根据当前的语言水平设置学习目标

定时的自我总结,从自己身上审视现状,然后制定下一步的策略

 

DDD的一个重要任务是,或者说是建模的重要任务是选取一个恰当的模型,使之能够与真实世界中的模型一样具有相同或近似的关系,所谓领域就是经过了多次的劳动实践得到了对model的深刻认识,能够从感性的认识上升到理性的认识

 

 

 

如何让软件插件化

如何让软件插件化

软件的插件化,核心是对软件进行抽象,达到一种程度使得所有人根据你抽象的模型编写完代码后能够顺利在核心软件开发者未知情况下直接使用。

很现成的例子是我们常用的插座:

目标:提供电力

如何使用:将电缆接入插座(plug-in/plug-out)

具体实现类:满足中国国标三口插座/两口插座

我们再以Spring启动事件为例,看一下Spring是如何实现的

Spring-Context初始化时候以以下函数为重点Application.refresh()

其中Fresh消息发布地方在FinishRefresh(),

在publishEvent中就能看到到底Spring是如何将其插件化的了:

重点在于需要现在把监听的对象通过spring ioc进行管理,然后就可以简单的通过订阅者模式进行事件的的发布。

划重点:

重点在于发布一个规范让所有人进行遵守,规范越是简单,那么就越灵活,越是复杂越是只能支持特定事物。

如Spring的需要两个要求,一个是对象需要通过Spring来管理并且需要实现一个特定接口。

所以另一个问题就是,如何得到规范,那就是考验设计者心智的情景了。